[BUG] CLI TUI: AskUserQuestion and permission prompts intermittently never render — session shows activity spinner indefinitely, queued messages never processed (2.1.167, Linux)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (closest is #65330, which is the macOS Desktop/Cowork surface — this is the CLI TUI on Linux)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (2.1.167)

What's Wrong?

Interactive dialogs (AskUserQuestion and Bash tool permission prompts) intermittently never render in the terminal. The session keeps showing the animated spinner with its gerund verb indefinitely, so it is indistinguishable from a hang. Any messages typed while waiting are queued behind the invisible dialog and never processed. The session only recovers when the user presses Esc / interrupts, at which point the pending prompt is resolved as denied/rejected — revealing after the fact that the CLI had been waiting on input the user never saw.

Two incidents on the same machine, same day (2026-06-06), both on 2.1.167:

Incident 1 — invisible AskUserQuestion (10+ minutes apparently hung)

Transcript (timestamps from the session .jsonl):

10:15:52Z tool_use   Bash        (grep — completed in 0.1s)
10:15:56Z tool_use   Read        (completed instantly)
10:16:27Z assistant_text
10:16:30Z tool_use   AskUserQuestion   <- LAST EVENT. Dialog never rendered.

The user saw only the spinner ("Tempering…") for 10+ minutes, typed 3 messages which queued and were never processed, and finally cancelled. After cancelling, the CLI revealed the question it had been waiting on; the user's verbatim reaction recorded in the transcript's last-prompt field:

"I never saw this prompt: \<two-option design question with a Recommended option\>"

The dialog content was well-formed (a normal two-option question) — it simply never appeared.

Incident 2 — invisible Bash permission prompt (different session, same machine)

A Bash call for a command not covered by the permission allowlist:

10:23:54.6Z tool_use    Bash   (ls -lt <dir>/*.jsonl | head -8)
10:26:13.5Z tool_result        <- +138.9s, and only because the user pressed Esc;
                                  recorded as "The user doesn't want to proceed with this tool use"

The underlying command runs in milliseconds. No permission dialog was ever displayed; the user watched a spinner for ~2.3 minutes before interrupting. The immediately preceding allowlisted/sandboxable Bash call in the same session completed normally in 1.5s.

During both stalls the claude process was idle in ep_poll (not spinning, not in D state) — consistent with waiting for user input on a prompt that was never drawn.

Possible trigger / correlation: in incident 1 the user had typed messages while the turn was still in flight (queued input present when the dialog should have rendered). Incident 2 may have had typed-ahead input as well. Suspect a race between the queued-message UI and dialog mounting.

Ruled out:

• Hooks: configured hooks only match Edit|Write|MultiEdit; the stalled calls were Bash/Read/AskUserQuestion.
• Long-running subprocess: ps confirmed the grep/ls subprocesses had exited almost immediately while the spinner continued.
• Theme/contrast issues (#57739): nothing was drawn at all — the spinner remained the active widget; a rendered-but-unreadable dialog would have replaced it.

Expected

The question/permission dialog renders; or, at minimum, the status line indicates "waiting on your input" rather than an activity spinner, so an undrawn dialog doesn't masquerade as model activity.

Environment

• Claude Code 2.1.167 (CLI, interactive TUI)
• Linux 6.17.0-29-generic, TERM=xterm-256color
• Both incidents in regular terminal sessions (no IDE extension, no SSH multiplexer involved)

Related

• #65330 / #65382 — same observable symptom (AskUserQuestion never renders, hangs until stop auto-denies) on the macOS Desktop/Cowork surface. Filed separately since the rendering stacks differ, but possibly a shared layer.