[META] Desktop: Keyboard operability is missing as a system — tracking issue for 32 open keyboard, focus, and shortcut reports

Summary

The Code tab can be driven with a mouse. It cannot reliably be driven with a keyboard. There are currently 32 open issues describing that, plus one filed alongside this, and they read as separate papercuts because each names a different button, dialog, or missing shortcut. Underneath they are a handful of root causes: no focus contract for dialogs, no deliberate way to move focus, no command registry to bind keys to, and nothing that checks per release whether any of it still works.

This meta-issue consolidates them so the gap can be prioritized as one systemic defect rather than three dozen feature requests. It follows the precedent of #81472, which did the same for copy/paste.

The common thread: The Desktop UI is built as a pointer surface with keyboard shortcuts bolted on per feature, rather than as a focusable UI with a keyboard contract. Where a keyboard path exists, someone added it for one specific control. Where nobody added one, there is none — and there is no user-side way to add one, because Desktop does not read keybindings.json (#84101). The CLI, by contrast, has a documented per-context binding system where a picker is a Select context with select:next, select:accept, and select:cancel, all rebindable. None of that reaches the Desktop UI.

Root causes and their issues

1. Dialogs and popups render without focus management

Portalled into the page, focus never moves into them, and the keys that would operate them are unbound. In each case the app is blocking on an answer the user cannot give from the keyboard.

• #90760 — AskUserQuestion option picker: Number keys highlight an option, Enter never accepts it, Tab skips the card and lands on Stop
• #82288 — bypass-permissions confirmation dialog renders off screen at the end of the page and never takes focus
• #82289 — slash-command suggestions render off screen; arrow keys do not move through them
• #77015 — clicking the notification for a pending question cancels the question instead of focusing it

2. Focus lands in the wrong place, or is silently dropped

• #84912 — submitting a prompt moves focus to the Stop button, so the next Enter cancels the running turn
• #90739 — selecting the working folder for a new session drops composer focus
• #82983 — the chat input intermittently cannot be focused by clicking at all
• #88670 — MCP UI widgets remount on session re-entry and steal scroll and focus

3. There is no deliberate way to move focus

Once focus is somewhere wrong, no keyboard gesture puts it back.

• #90743 — no shortcut to focus the chat composer
• #89910 — no shortcut to move focus between panes (terminal, chat, diff) without toggling them
• #78851 — no keyboard route to the working-directory picker

4. Nothing is rebindable, so none of these defects has a user-side workaround

• #84101 — Desktop does not read keybindings.json
• #86641 — Ctrl+/ never matches on layouts where / needs Shift, so the shortcut list itself is unreachable
• #78002 — zoom shortcuts bound to physical US key positions, wrong keys on a Norwegian layout

5. Common actions exist only as pointer affordances

Each of these is filed as its own feature request. Together they are one request: actions available in the UI should have keyboard equivalents.

• #89948, #80501 — delete a session
• #72426 — open a session's context menu in the left panel
• #82190 — jump to the next session awaiting input
• #90624 — cycle sessions in most-recently-used order
• #77905 — keyboard-navigable session list
• #70678 — jump between user messages in the transcript
• #86642 — Reply, and Attach selection as context
• #86758 — toggle the Background tasks panel
• #90576 — voice dictation
• #69993 — pane splitting

6. The shortcut layer intermittently fails wholesale

• #89805 — Enter-to-submit and the session menu's letter shortcuts stop working together, then return together
• #48435 — keyboard scrolling of the response stopped working
• #89158 — typed key events arrive duplicated

7. Nothing checks any of this before release

• #71469 — screen-reader regression testing is not part of the desktop release process
• #87977 — VoiceOver navigation jumps the cursor around; sidebar and sessions are hard to move through
• #76252 — VoiceOver re-announces the composer repeatedly during a turn

8. What exists is hard to discover

• #81920 — Markdown formatting shortcuts are neither documented nor exposed
• #90317 — non-obvious interactions (split view, rewind, pickers) have no in-app affordance
• #86641 again — the one surface that would answer "what can I press here" is itself unreachable on some layouts

What a fix looks like

Three things, in order of how much each one unblocks:

1. A focus contract for dialogs and popups. When a blocking UI opens, focus moves into it; Enter accepts the highlighted item; Escape cancels; Tab cycles within it and does not escape to controls behind it; focus returns where it came from on close; and the container is exposed to the accessibility tree with a dialog role and an accessible name. That single contract closes group 1 outright and makes groups 2 and 7 testable.
2. A command registry with rebindable keys, as the CLI already has (#84101). Every item in group 5 then becomes a registered command instead of a separate feature request, and every defect in this list gains the user-side workaround it currently lacks.
3. A keyboard smoke check in the release process (#71469): open each blocking dialog, answer it from the keyboard alone, confirm focus lands inside and returns on close.

Why file this as one issue

Individually these are small enough to sit unfixed and be closed as stale — several already carry the label. Together they describe an app a keyboard-only user cannot operate and a mouse user is repeatedly yanked out of. The reports that are outright accessibility blockers (#82288, #82289, #87977) and the ones that read as convenience (#90624, #86758) have the same cause and the same fix, which is why triaging them separately has not converged on one.

Happy to keep the list current as reports are filed or closed.

Environment for the reports filed from this setup: Claude Desktop 1.40609.0 (Microsoft Store MSIX build), bundled engine claude-code 2.1.247, Windows 11 Education 25H2 build 26200.