Permission prompt key numbering differs between CLI and Desktop /remote-control

Description

When using /remote-control to approve/deny permission prompts from Claude Desktop, the numbered keyboard shortcuts do not match the numbering shown in the CLI terminal, which can lead to accidental approval/denial of the wrong option.

Steps to reproduce

1. Start a Claude Code session in a terminal (CLI).
2. Trigger a permission prompt (e.g., a sudo command).
3. Observe the CLI prompt:

```
Do you want to proceed?
> 1. Yes

1. Yes, and don't ask again for: <command>
2. No

```

1. Connect via /remote-control and view the same pending prompt in Claude Desktop.
2. Observe the Desktop prompt:

``
Deny 1 Always allow 2 Allow once 3 (Ctrl+Enter)
``

Expected behavior

The number assigned to "approve" vs "deny" should be consistent between the CLI and the Desktop /remote-control view, so a user switching between the two doesn't accidentally press the wrong number.

Actual behavior

• CLI: pressing 1 = Yes (approve)
• Desktop (/remote-control): pressing 1 = Deny

This inversion is confirmed via side-by-side screenshots of the same pending prompt.

Suggested fix

Align the option ordering/numbering (or at minimum the keyboard shortcut number) between the CLI and Desktop /remote-control views for the same prompt type, or clearly visually differentiate them so users don't rely on muscle memory across interfaces.