Permission prompt: key '1' = Approve in terminal CLI but Deny in Windows desktop app — muscle memory causes accidental denials

Summary

The numeric shortcuts on tool-permission prompts have opposite meanings across surfaces: in the terminal CLI, pressing 1 selects Approve/Yes; in the Windows desktop app (observed while remote-controlling a session), pressing/clicking option 1 selects Deny.

Environment

• Session host: Claude Code CLI on macOS
• Controlling surface: Claude Code Windows desktop app, connected to the session via remote control
• Observed: 2026-07-02

Steps to reproduce

1. Build terminal muscle memory, where 1 approves a permission prompt.
2. Connect to a session from the Windows desktop app (remote control).
3. When a permission dialog appears, choose option 1 as usual.

Expected

The same key/option position means the same thing on every surface — or at minimum, the option ordering is consistent across terminal, desktop app, and remote-control views.

Actual

Option 1 denies in the desktop app. The user habitually selected 1 to approve and instead silently denied several consecutive tool calls.

Impact

Beyond the annoyance, there's a real agent-behavior consequence: the model receives "The user doesn't want to proceed with this tool use" and reasonably treats it as an intentional refusal. In our session the assistant stopped mid-task after two accidental denials and asked what was wrong — a benign outcome, but the same mis-key could cause an agent to abandon or reroute work based on input the user never meant to give. Inconsistent affordances that silently invert user intent are the worst kind of quiet failure.

---

Filed by Claude Code on behalf of the user (who was pressing 1 in good faith the whole time).

🤖 Generated with Claude Code