/permissions arrow-key navigation inert when auto-mode denials are present (2.1.221, macOS) — still live after #57659 closed stale

Summary

/permissions renders but accepts no arrow-key navigation — the menu appears frozen and ↓ does not move the highlight, so no rule can be selected and Add a new rule… cannot be reached.

This is a still-live reproduction of #57659, which was closed NOT_PLANNED by the staleness bot on 2026-06-14 with "Closing for now — inactive for too long. Please open a new issue if this is still relevant." It is still relevant. Filing fresh as instructed rather than commenting on a closed issue.

Environment

• Claude Code 2.1.221 (latest on npm at time of filing: 2.1.233 — not yet upgraded, so this may already be fixed; filing because #57659 was closed unfixed and there is no fix reference to check against)
• Platform: macOS, Darwin 22.6.0
• Shell: bash
• Model: Claude Opus 5 (1M context)
• Auto mode active
• Recently-denied entries present: yes — see below

Why this report adds something: the denial-state trigger reproduced naturally

The most useful comment on #57659 (from moonexpr, via binary analysis of 2.1.142) argued the trigger is the presence of recently-denied entries, not the Allow tab specifically — the theory being that the ↑/↓ cursor is bound to the rule-options model while the denials list is a separate getDenials() render path whose rows are not registered in that cursor model.

This session is an unplanned confirmation of that shape. In the minutes immediately before /permissions was opened, the auto-mode classifier issued two denials:

1. A Bash call from a subagent running the project's Playwright suite.
2. An Edit call against .claude/settings.json — the assistant attempting to add the very allow rule that would have prevented denial #1.

/permissions was then opened specifically to add that rule by hand, and was found unnavigable. So: denials present → navigation inert, matching the comment's prediction rather than the original report's "Allow tab only" framing.

I did not personally observe the frozen UI (the user did, and reported it); the version, platform, auto-mode state, and the two denials are directly verified from this session.

Impact

There is a circularity worth calling out explicitly, because it makes this worse than a cosmetic TUI bug:

• The auto-mode classifier correctly refuses to let an agent edit .claude/settings.json to grant itself permissions. That is a good boundary and should stay.
• Which means the human is the only one who can add the allow rule.
• /permissions is the human's discoverable path to do that.
• When /permissions is inert specifically because denials exist, the tool is broken at exactly the moment it is needed. Every denial makes the fix for that denial harder to reach.

The remaining path is hand-editing permissions.allow in a settings file, which is undiscoverable for anyone who does not already know the rule syntax.

Repro

1. Run Claude Code in auto mode.
2. Trigger at least one auto-mode classifier denial (any command the classifier blocks).
3. Run /permissions.
4. Try to navigate with ↑/↓.

Expected: highlight moves through the rule list; Add a new rule… is reachable.
Actual: highlight does not move; the footer still advertises ↑/↓ to navigate.

Suggested triage

If the selection-model gap in #57659's last comment is accurate, the fix is registering the denials rows in the same cursor model as the rule options (or excluding them from it consistently) so the advertised ↑/↓ contract holds on every tab regardless of denial state.

Separately: it would help a lot if the footer hint degraded honestly — advertising ↑/↓ to navigate on a list that cannot be navigated is what makes this read as "frozen app" rather than "unsupported control."