Skip to content

fix: say why a key has no receiver and point to the menu - #14

Merged
iamnbutler merged 1 commit into
mainfrom
key-hint
Oct 15, 2026
Merged

iamnbutler merged 1 commit into
mainfrom
key-hint

Conversation

@iamnbutler

Copy link
Copy Markdown
Contributor

In the Ace desktop tools study (githubnext/ace#427, scenario D2), desktop_key Escape to a Finder window was refused with "Click a control, then inspect the window again." The agent clicked a file row and tried again, which can't work: the key needs a focused element in the snapshot.

The key refusal now says the key has no verified receiver. It points to the menu when the command has one, and says to check that the new snapshot reports focus before retrying. The insert refusal now names the text field. Fixing the underlying limit is #13.

Found in the Ace desktop tools study (githubnext/ace#427, D2): Escape in Finder was refused and the old
hint sent the agent into a click-and-retry loop that could not succeed. Tracks #13.
@iamnbutler
iamnbutler merged commit 25851fd into main Oct 15, 2026
2 checks passed
iamnbutler added a commit to githubnext/ace that referenced this pull request Oct 15, 2026
)

* fix(channel): pin desktop-tools with clearer menu and key refusals

Moves desktop-tools from 20cb1b5 to 034a695:
- githubnext/desktop-tools#15: a menu path with no match names the missing title, its level and the titles at that level, and suggests "Save…" for "Save".
- githubnext/desktop-tools#14: a key with no focused receiver says why, and points to the menu.

desktop_menu's description now says titles match exactly, ellipses included. The docs point to Settings → Computer use for permissions.

Found in the desktop tools study, D1 and D2 (#427).

* chore: confirm package.json notes after the desktop-tools pin bump
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant