[Bug] claude_code: AskUserQuestion/plan dialogs classify as idle/completed — inbox delivery auto-answers user decision dialogs

[chaogebaba]

Symptom

When a claude_code terminal is showing an interactive decision dialog (AskUserQuestion option picker, plan-approval prompt), the provider's status detection classifies the screen as idle or completed — not waiting_user_answer.

Because inbox delivery gates only on idle/completed, a queued message is then delivered into the dialog: the message text is typed and the trailing Enter submits the currently-focused dialog option (for AskUserQuestion that's the first/"Recommended" one). A worker's callback can literally answer a human's decision dialog.

Observed live

2026-07-09 ~17:59 (local logs): a supervisor terminal's AskUserQuestion dialog was auto-answered by an incoming worker-callback delivery — the Enter keystroke selected the recommended option without any human input.

Root cause pointer

• src/cli_agent_orchestrator/providers/claude_code.py — status detection has no WAITING_USER_ANSWER classification for AskUserQuestion / plan-approval screens; the surrounding idle chrome wins.
• src/cli_agent_orchestrator/services/inbox_service.py — delivery treats idle/completed as safe-to-type.

Any dialog-protection layer that defers delivery on waiting_user_answer is inert for these screens because the classification never happens.

Suggested direction

Classify Claude Code's decision dialogs (option list + keyboard-focus chrome) as WAITING_USER_ANSWER so delivery holds until the human answers. A conservative screen-pattern match on the AskUserQuestion frame is enough; false-WAITING is far safer than auto-answering a user decision.

Found while operating a long-running multi-agent fork of this repo; happy to provide captured frames.

[haofeif]

@call-me-ram would you like to have a look ?

[call-me-ram]

Confirmed against current main. Our WAITING_USER_ANSWER detection for claude_code keys on the single literal Ink footer ↑/↓ to navigate (providers/claude_code.py), so any AskUserQuestion / plan-approval frame that doesn't render exactly that string classifies as idle/completed — and inbox delivery gates only on idle/completed, so it types into the dialog with a trailing Enter and auto-answers the human's decision. That's the mechanism behind what you observed.

Agreed on direction: broaden the dialog classification (option-list + focus chrome patterns) so delivery holds — a false-WAITING is far safer than auto-answering a decision dialog. You mentioned captured frames; please attach them (or the raw pane dumps) so the new patterns match the real chrome across TUI versions. Happy to take a PR from your fork, otherwise we'll fold it in.

[chaogebaba]

You can fold it in . i will use your fix . i am a vibe coder. dont know how to pick a commit to fire a PR

[call-me-ram]

No problem — we'll take the fix from here, thanks for the clear report.

One ask so we don't regress the other direction: broadening the WAITING_USER_ANSWER classification is the one change here that can genuinely break things (an over-broad pattern makes ordinary output classify as a dialog and inbox delivery stalls forever), so we want real captured frames to pin the patterns against before touching detection. If you still have them, plain screenshots of the AskUserQuestion picker and the plan-approval prompt are enough — otherwise we'll reproduce locally and build the frame corpus ourselves. Tracking this as maintainer-owned now; #413 and #414 are being fixed first since they're already fully specified.

[chaogebaba]

Frames attached — issue-405-frames.zip: AskUserQuestion and plan-approval pickers, plain + escape-preserving (tmux capture-pane -p / -pe), byte-exact and untrimmed, with a README recording CLI version, date, pane geometry and correct status per frame.

Capturing them turned up three things, and one of them cuts against my own issue title — the report conflated two different mechanisms.

1. AskUserQuestion already classifies correctly. The picker does render ↑/↓ to navigate, on both the version from the incident (2.1.205) and current 2.1.209. So for that dialog the existing pattern fires and delivery defers as designed. I confirmed this independently at the time: with a worker parked at a steady-state AskUserQuestion, a queued send_message (id 948) stayed PENDING and was never typed.

Which means the auto-answer I reported at 17:59:45 — which was an AskUserQuestion — was not a classification miss. It was a race in inbox_service.deliver_pending: status is read once at entry, then the actual keystroke happens seconds of DB+tmux I/O later, and nothing re-checks in between. A dialog that opens inside that window gets typed into by an already-passed guard. Broadening the pattern would not have prevented it.

2. Plan-approval is a real classification gap — your diagnosis is right for that frame. It renders no nav footer at all. Verbatim chrome (2.1.209):

   Claude has written up a plan and is ready to execute. Would you like to proceed?
   ❯ 1. Yes, and bypass permissions
     2. Yes, manually approve edits
     3. No, refine with Ultraplan on Claude Code on the web
     4. Tell Claude what to change
        shift+tab to approve with this feedback
   ctrl+g to edit in  Nvim  · ~/.claude/plans/recursive-plotting-candle.md

Different chrome entirely: ❯ N. option list, shift+tab to approve with this feedback, ctrl+g to edit in. Nothing the current pattern can see. (Fair warning on the frame in the corpus: its scrollback happens to contain the nav-footer string, because the plan file I was approving quoted it. The dialog region itself has none — that's the part to pin against, and the README flags it.)

3. The stall regression you're worried about already exists, and it's an anchoring bug, not a breadth one. get_status does re.search(WAITING_USER_ANSWER_PATTERN, output) over the whole screen. So any agent that merely prints ↑/↓ to navigate in ordinary output makes its own terminal classify WAITING_USER_ANSWER while genuinely idle — and inbox delivery then stalls forever. Frame 03 in the corpus is exactly that: idle composer, no dialog, classifies WAITING. I hit it by accident just by writing about this issue in a terminal you were watching.

get_status_from_screen already restricts to a bottom region and gets that frame right. get_status doesn't. Whatever new patterns you add, anchoring them to the bottom chrome region looks like the thing that decides whether broadening is safe — an unanchored option-list pattern would make every agent that renders a numbered list stall its own inbox.

One more data point for pattern choice: the footer literal drifted between the two versions I have —

• 2.1.205: Enter to select · ↑/↓ to navigate · Esc to cancel
• 2.1.209: Enter to select · ↑/↓ to navigate · n to add notes · Esc to cancel

· n to add notes was inserted mid-footer, and ↑/↓ to navigate survived intact. Matching more of the footer literal would have broken on that upgrade; the current substring didn't.

Reproducing: frame 01 is any AskUserQuestion call; frame 02 is EnterPlanMode → write a plan → ExitPlanMode; frame 03 is printing the pattern string in normal output and going idle. Capture with tmux capture-pane -p -t <session>:<win>.<pane>. For the original race, the shape is: park a claude_code worker, queue a message, and have a dialog open during the delivery window rather than before it.

Happy to capture more frames on request — other TUI versions, multi-select, free-text mode, narrower panes. Just say which.

issue-405-frames.zip

[chaogebaba]

Captured the frames. They turned up three things, and one cuts against my own issue title — the report conflated two different mechanisms. Line references below are against upstream/main @ 32db5a1.

1. AskUserQuestion already classifies correctly

The picker does render ↑/↓ to navigate, on both the version from the incident (2.1.205) and current 2.1.209:

 ☐ Color
Pick a color?
❯ 1. Red
     The color red
  2. Blue
     The color blue
  3. Type something.
────────────────────────────[separator truncated]────────────────────────────
  4. Chat about this
Enter to select · ↑/↓ to navigate · Esc to cancel

(Only the full-width separator is truncated for readability; the byte-exact capture is available.)

So for that dialog the existing pattern fires and delivery defers as designed. I confirmed this independently at the time: with a worker parked at a steady-state AskUserQuestion, a queued send_message (id 948) stayed PENDING and was never typed.

Which means the auto-answer I reported at 17:59:45 — which was an AskUserQuestion — was not a classification miss, and broadening the pattern would not have prevented it. See §4.

2. Plan-approval is a real classification gap — your diagnosis is right for this frame

It renders no nav footer at all. Verbatim chrome, 2.1.209:

   Claude has written up a plan and is ready to execute. Would you like to proceed?
   ❯ 1. Yes, and bypass permissions
     2. Yes, manually approve edits
     3. No, refine with Ultraplan on Claude Code on the web
     4. Tell Claude what to change
        shift+tab to approve with this feedback
   ctrl+g to edit in  Nvim  · ~/.claude/plans/recursive-plotting-candle.md

Different chrome entirely: ❯ N. option list, shift+tab to approve with this feedback, ctrl+g to edit in. Nothing the current pattern can see.

3. The stall regression you're worried about already exists — it's an anchoring bug, not a breadth one

get_status does re.search(WAITING_USER_ANSWER_PATTERN, output) over the whole screen (providers/claude_code.py:552). So any agent that merely prints ↑/↓ to navigate in ordinary output makes its own terminal classify WAITING_USER_ANSWER while genuinely idle — and inbox delivery then stalls forever. I hit this by accident: writing about this issue in a terminal, with no dialog open, was enough. Idle composer, nothing focused, classifies WAITING.

get_status_from_screen already restricts to a bottom region (claude_code.py:686) and gets that same frame right. get_status doesn't.

That makes anchoring, not breadth, the thing that decides whether your fix is safe — an unanchored option-list pattern would make every agent that renders a numbered list stall its own inbox.

One more data point for pattern choice — the footer literal drifted between the two versions I have:

• 2.1.205: Enter to select · ↑/↓ to navigate · Esc to cancel
• 2.1.209: Enter to select · ↑/↓ to navigate · n to add notes · Esc to cancel

· n to add notes was inserted mid-footer; ↑/↓ to navigate survived intact. Matching more of the footer literal would have broken on that upgrade. The substring didn't.

4. The fix, as far as our fork got

Two independent defects, and #405 needs both — this is the part I got wrong in the original report, so treat it as a hint rather than a spec:

(a) Detection — anchor first, then broaden. Anchoring get_status to the bottom chrome region the way get_status_from_screen already does is worth doing on its own: it fixes the §3 stall, and it's what makes adding a plan-approval pattern safe rather than a new false-WAITING surface. Broadening on top of the unanchored search would widen the stall. For the plan frame, Would you like to proceed? plus the ❯ N. list within the bottom region held up across our captures; the ctrl+g to edit in / shift+tab to approve lines are the stable chrome.

(b) Delivery — the race is what actually auto-answered the dialog. In deliver_pending, the status guard reads at inbox_service.py:79, messages are marked DELIVERED at :103, and the keystroke lands at :115/:117 — with DB and tmux I/O in between. Nothing re-checks. A dialog that opens inside that window gets typed into by an already-passed guard, and #164's mark-before-send doesn't help, because the mark isn't atomic with the read. There's also no per-terminal lock, and deliver_pending has several concurrent callers besides the sequential status-event consumer (immediate delivery on message POST, watchdog, reconcile sweep, pollers) — two of them can both see the same message PENDING and both send. We saw duplicate send_keys pairs 4ms apart three times in one session.

What worked for us: a per-terminal lock held across get→mark→send, plus a status re-check immediately before each send_input that defers (resets to PENDING) instead of typing. That closes the multi-second window. The residual is a dialog opening inside the keystroke window itself — milliseconds, and we found no terminal-side primitive that closes it, so we treat dialog protection as best-effort and the dedup as the hard guarantee.

Worth noting (a) alone won't close this issue: with detection fixed, the AskUserQuestion incident still reproduces through the race.

Reproducing

• Frame 1: any AskUserQuestion call in a claude_code terminal.
• Frame 2: EnterPlanMode → write a plan → ExitPlanMode.
• Frame 3 (the stall): have the agent print ↑/↓ to navigate in ordinary output, then let it go idle. Status reads WAITING with no dialog on screen.
• The race: park a claude_code worker, queue a message, and have the dialog open during the delivery window rather than before it.

Capture with tmux capture-pane -p -t <session>:<win>.<pane> (add -e to keep escapes).

I have the four frames byte-exact, plain + escape-preserving, with a README recording CLI version, pane geometry and correct status per frame — happy to attach the archive here, PR them as fixtures, or capture more on request (other TUI versions, multi-select, free-text mode, narrow panes). Just say which is easiest for you.

written by opus 4.8