Summary

AskUserQuestion (or equivalent question/modal tool) renders a question pane that is completely undismissable under the Claude Opus 4.7 orchestrator. Esc, Ctrl-C, and Ctrl-X all no-op. Arrow keys + Enter do navigate and submit a selection, but after submission a new identical question appears, trapping the user. Worse — characters typed while attempting to recover land in the "Type your own answer" field as silent state corruption that persists across re-renders.

This is not the ESC-race issue #20095 (fixed in v1.3.3+ via the Effect/Runner migration). I am on v1.14.50 — that code path is gone. This is a new failure mode.

Closest open/closed cousins: #9284 (auto-closed stale, model-side loop), #11367, #26849, #23515 (all open UX issues).

Environment

Steps to reproduce

1. Run an Orchestrator agent on Claude Opus 4.7 with a long-running multi-perspective workflow.
2. The agent eventually emits a AskUserQuestion-style modal with 6 options + "Type your own answer".
3. User presses Esc — modal does not dismiss.
4. User presses Ctrl-C — no effect.
5. User presses Ctrl-X — no effect.
6. User attempts to type a free-text reply ("continue", with a typo contineu) — characters land in the "Type your own answer" field but no Enter is fired (TUI swallows it because the input is in select-mode, not text-mode).
7. User then arrow-navigates (Down Down) to option feat: model config persistence #3 and presses Enter.
8. Option feat: model config persistence #3 IS submitted — agent proceeds, does real work (git commit, git push, updates a status file).
9. Agent emits "Going to waiting" and is genuinely idle.
10. BUT the original modal is still visible, with the contineu typo still in the custom-answer field and option feat: model config persistence #3 still checkmarked from step 7. A second identical question is queued behind it. User is trapped in the loop again.

Expected

• Esc should dismiss the modal cleanly and return to the normal prompt.
• Ctrl-C should interrupt the in-flight question and return control to the user.
• After a successful selection + Enter in step 7, the modal should fully tear down before the agent fires a new one.

Actual

• Esc / Ctrl-C / Ctrl-X are dead-keys while the modal is open.
• Free-text typed while in select-mode silently corrupts the "Type your own answer" field — the user has no visual indication this is happening, and the corruption persists across modal re-renders.
• Submitting an option does not tear down the modal; the next question appears layered on top of the old one.
• No CLI / API workaround documented anywhere.

Pane capture (anonymised)

┃  Done. Tier 3 P9+P10 planning artifacts committed (e375435) and pushed. ...
┃  Going to waiting.
┃
┃  What should I tackle next? Everything remaining needs your call.
┃
┃  1. Publish [report] + update PR #1
┃  2. Sub-RPI: P5/P8 LLM challenger
┃  3. Tier 3 P9 + P10 sub-RPI✓                          ← previously selected
┃  4. Decide M4 [external-tool] nightly policy
┃  5. Decide P1 FAIL bug treatment
┃  6. Pre-cache [data file]
┃  7. Type your own answer
┃     contineu                                            ← my recovery typo
┃
┃  ↑↓ select  enter submit  esc dismiss                  ← esc DOES NOT WORK
┃
▣  Orchestrator · Claude Opus 4.7 · 41.5s                 ← agent is idle

The "esc dismiss" footer hint is lying — esc is bound but does nothing.

What I had to do to recover

Kill the entire OpenCode session via external orchestrator (concierge kill <name>) and re-spawn against the same project directory. Lost only the in-flight Oracle task — committed state on disk was preserved. This should not require killing the whole session.

Cross-references

• #9284 — agent re-asks in loop (closed stale, not fixed). Symptom overlaps but root cause may differ.
• #20095 / #20250 — ESC race (fixed v1.3.3+). I'm on v1.14.50, so this is a new failure mode, not a regression of that fix.
• #11367, #26849, #23515 — open UX issues on the question modal.
• #24988 (shipped v1.14.51) — preserved text selection on question prompts, but does not address dismiss / escape.

Suggested fixes

1. Make Esc actually fire Question.dismiss() instead of being a no-op (the footer claims it works).
2. Make Ctrl-C always interrupt — current behavior leaves the user with no escape hatch.
3. When the user is in option-select mode, either route stray keystrokes to the custom-answer field only if they explicitly tab/select into it, or display the typed buffer visibly so users know it's being captured.
4. Fully tear down the previous modal before rendering a new question, so a successful submit doesn't visually overlap with the next question.