Inconsistent Hotkey for Command Approval

Confirmed on main @ 1f41cc5d92, and the hazard is structural: digit hotkeys select by position, while the option count varies per approval.

Digits resolve through actual_idx_for_enabled_number — i.e. "2" = the second enabled row, whatever it happens to be (tui/src/bottom_pane/list_selection_view.rs#L1054-L1061). Meanwhile the option list is contextual: the "Yes, and don't ask again for commands that start with …" row is only offered for single-line commands, and the session-scope row is also conditional (approval_overlay.rs#L840-L910). So across a burst of sequential approvals the popup alternates between 3-option and 2-option layouts, and "2" flips between approve-for-session and decline — exactly the muscle-memory trap you hit.

Two things worth knowing / two fix shapes:

• Stable semantic keys already exist: y = approve, a = approve for session, p = approve for prefix, and the deny binding (keymap.rs#L1335-L1337) — these don't shift with layout. If the popup's hint line advertised them more prominently, digit-reliance would fade. (They're also remappable via [tui.keymap].)
• Digits could be made stable too: assign fixed digits per semantic slot (e.g. 1 = plain yes, 2 = yes-with-scope, 9/0 or n = no) and simply skip unused digits when a row is absent, instead of compacting positions. Positional numbering is the only scheme in which the same key can mean "yes" and "no" on consecutive prompts — for an approval dialog specifically, that's worth ruling out by construction. A related guard: never let a digit that meant an affirmative in the previous prompt map to a destructive/negative option in the next one.

Test shape: render the approval popup with and without the prefix/session rows and assert the digit → decision mapping is identical in both layouts.