/permissions dialog: keyboard focus can't enter the rule list (can't add allow rules); no Shift+Tab bypass — auto-denied commands become a dead end

Summary

In the classifier-based auto-approve/deny permission mode, commands were being auto-denied with no interactive path to allow them, because the /permissions dialog and the Shift+Tab mode-cycle are both effectively unusable for the one thing they're meant to fix:

1. /permissions dialog: keyboard focus cannot enter the rule list. The dialog opens on the Allow tab. The footer reads ←/→ to switch · ↓ to select · Esc to cancel, but pressing ↓ (down arrow) does not move focus off the tab row into the list (whose first item is "Add a new rule…"). Left/right only cycle the tabs. There is no way to reach "Add a new rule…", type a rule, or focus the Search field via the keyboard. The dialog is a dead end.
2. Shift+Tab offers no bypass mode. Cycling permission modes with Shift+Tab did not surface a "bypass permissions" option — it only toggled the standard modes — so the guard could not be disabled interactively either.

Net effect: when the classifier auto-denies a command, the user is stuck. The documented remediation ("add an allow rule in /permissions", "Shift+Tab to bypass") is unreachable from the keyboard, forcing a manual settings.json edit or running the command outside the agent. For a user mid-task on a legitimate operation, this reads as the tool silently refusing to work with no way out — a very bad failure mode.

Environment

• Claude Code 2.1.226
• macOS (Darwin 25.3.0)
• Permission mode: auto (classifier auto-approve/deny)

Steps to reproduce

1. Run a session in the auto-approve/deny permission mode.
2. Issue a command the classifier auto-denies (e.g. ssh <prod-host> '<privileged command>'). It is denied silently, with a message suggesting you add a Bash allow rule in /permissions.
3. Run /permissions; it opens on the Allow tab.
4. Press ↓ to select the first list item ("Add a new rule…").

Expected: ↓ moves focus into the list so "Add a new rule…" can be selected and a rule typed (or the Search field can be focused).

Actual: Focus stays on the tab row; ↓ does nothing; the list and Search field cannot be reached. No rule can be added. Separately, Shift+Tab exposes no bypass mode.

Impact

High friction / dead-end. A user cannot self-serve past an auto-deny using the in-product UI as documented. The only escapes are editing .claude/settings.json ("permissions": {"defaultMode": "bypassPermissions"}) by hand or relaunching with --dangerously-skip-permissions — neither discoverable in the moment.

Suggested fixes

• Make ↓ / Tab move focus from the tab row into the rule list (and to the Search field), matching the footer hint ↓ to select.
• Ensure "Add a new rule…" is reachable and actionable by keyboard and mouse click.
• Surface a keyboard path to a bypass/ask mode (e.g. include it in the Shift+Tab cycle, or a dialog action), so an auto-denied command can always be resolved without leaving the UI.
• When a command is auto-denied, offer an inline "Allow this / Allow pattern" affordance rather than only pointing at a dialog that may be unreachable.