[Bug]: Claude Code runner does not wait for AskUserQuestion — agent continues without an answer

[cbeaulieu-gt]

Before you submit

• I searched existing issues and confirmed this is not a duplicate.
• I replaced the example text with the real behavior, reproduction steps, expected result, and version.

What happened?

When the Claude Code runner emits an AskUserQuestion tool call, the runner does not pause for the user's answer — the agent continues executing on its own, even if no option is selected. The question card renders and is interactive (selecting an option flips it to a locked "accepted" state), but the run has already moved on by that point. I don't know whether it's even possible to submit an answer early enough for the agent to use it, or whether by the time the card is visible the agent has already continued.

This appears to happen because claude -p (headless print mode) does not block on host tool results: it auto-fires an error tool_result for the unanswered AskUserQuestion and continues the turn. Separately, the card's "accepted" state is set optimistically in the UI before/independently of any backend delivery, so it can look accepted even though the answer never reached the running agent.

Steps to reproduce

1. Open Open Design (no custom skill or design system required).
2. Start a chat run with the Claude Code runner and prompt the agent so it calls AskUserQuestion.
3. Wait for the AskUserQuestion card to appear.
4. Do nothing — do not select an option.
5. Observe: the agent continues executing without waiting for any input.
6. (Optionally) select an option afterward: the card flips to "accepted," but the run has already proceeded without it.

Expected behavior

When the agent calls AskUserQuestion, the runner should pause the run and wait for the user to choose an option and submit, then resume using that answer as the tool result. The agent should not continue until an answer has been provided (or the user explicitly dismisses/cancels).

Open Design version: 0.9.0 (stable)

Platform: Windows

Logs (optional): Not included — packaged stable app; the contributor pnpm tools-dev logs --json command assumes a local dev checkout. Happy to provide if a maintainer points to the installed Windows app's daemon log location.

Additional context

Root cause spans two layers: (1) Claude Code CLI — claude -p does not block on host tool results (expected for headless print mode); (2) Open-Design UI — ToolCard.tsx sets setSubmitted(true) before the POST to /api/runs/:id/tool-result resolves, so the card always appears accepted, and on a non-200 the onSubmitForm fallback sends the answer as a new user message (a fresh turn) rather than answering the pending tool call. Minimal UI-side fix: gate setSubmitted(true) on ok === true, and surface a clear failure when the answer can't be delivered.

🤖 Generated by Claude Code on behalf of @cbeaulieu-gt

[open-design-bot]

🎉 ✨ Welcome to Open Design, @cbeaulieu-gt!

✨ 🔥 Lit the spark.

🌱 Your first contribution adds energy to the project. Thanks for showing up and helping Open Design grow.

💛 Thanks for helping Open Design grow. Keep building in the open. 🚀

🔗 Share on X (English) · 分享到 X（中文）

[lefarcen]

Hey @cbeaulieu-gt — thanks for the very thorough repro and for tracing both layers here. The split you called out between the Claude runner behavior and the optimistic UI state is exactly the useful detail.

I checked the current code path, and the UI-side symptom is real: the AskUserQuestion card marks itself submitted before the /api/runs/:id/tool-result round-trip is confirmed, and if that live submit fails it falls back to sending the answer as a fresh user message instead of satisfying the pending tool call. That matches the “accepted in the card, but the run already proceeded without it” behavior you described.

This also doesn’t look like a duplicate of the earlier AskUserQuestion work in #1743 / #3582 — those improved the wiring/rendering surface, while this report is about the wait/submit path once the card is already on screen. I’ve labeled this as a bug and help wanted; it looks like a real runtime/UI coordination issue rather than just a reporting artifact. If we can get a focused fix in, the likely first step is exactly where you pointed: only lock the card after the live tool-result write succeeds, and make the failure state explicit when the run is no longer accepting that answer.

[lefarcen]

If anyone in the community wants to take this on, feel free to comment /claim and pick it up.
This looks like a solid bug to tackle around the AskUserQuestion submit/wait path.

[lefarcen]

Heads-up: PR #3833 is now open against this bug.
It tackles the UI-side half of the issue by only locking the AskUserQuestion card after the live /api/runs/:id/tool-result delivery succeeds, and it adds regression coverage for the false/throw fallback paths.
Keeping #3808 open until that PR lands.

[cbeaulieu-gt]

Investigation: headless claude cannot pause for an AskUserQuestion answer

I dug into the root cause before picking a fix, and the result changes how this issue should be approached. TL;DR: the agent doesn't pause because headless claude -p auto-resolves AskUserQuestion with an error tool_result and ends the turn — there is no point at which a host-supplied answer can reach the original tool call. The fix therefore cannot be a UI-only change.

How I tested it

Driving the real claude binary (CC 2.1.168) the same way the daemon does — apps/daemon/src/runtimes/defs/claude.ts spawns -p --input-format stream-json --output-format stream-json --verbose --permission-mode bypassPermissions — and inspecting the raw JSONL for the stop_reason on the turn where the tool fires.

Probe	Permission mode	stdin	Turn outcome
1	default	closed	AskUserQuestion → auto-error tool_result → end_turn @ ~13s
2	bypassPermissions (daemon's real flag)	closed	identical → end_turn @ ~14s
3	bypassPermissions	held open ~75s	identical auto-error → end_turn @ 14s (duration_ms: 14179); process merely lingered until stdin EOF, then exited

The exact sequence, every time:

assistant → tool_use: AskUserQuestion
user      → tool_result { is_error: true, content: "Answer questions?" }   ← auto-injected by the runtime, no host involved
assistant → "…waiting for your answer"                                     ← model narrates waiting, but:
result    → stop_reason: end_turn, terminal_reason: completed,
            permission_denials: [ AskUserQuestion ]

Why this matters

• Holding stdin open does not help. Probe 3 kept stdin open for 75s (exactly what the daemon relies on between turns). The turn still completed at 14s — process-alive ≠ turn-paused. The comment at apps/daemon/src/runtimes/defs/claude.ts:50-56 ("--input-format stream-json … is what lets us answer Claude's AskUserQuestion tool calls with a real tool_result block") describes intended behavior that the binary does not actually exhibit.
• AskUserQuestion lands in permission_denials even under bypassPermissions — it is structurally unanswerable in --print mode, not a permission-config issue.
• By the time a human clicks, the run is already terminal. So POST /api/runs/:id/tool-result returns 410 essentially every time, and the answer can only route through the onSubmitForm fallback as a new user turn.

Relationship to #3833

#3833 is a correct and worthwhile hardening — it stops the card from falsely showing "accepted" before delivery is confirmed, and adds regression tests. But given the timing above, the live route will fail ~always (run already terminal), so in practice the card never locks and the answer always falls back to a detached new chat message. It does not remove the phantom "waiting for your selection" text, and the tool is still asked-and-auto-errored under the hood. In other words, #3833 fixes a real secondary race but not the user-facing symptom this issue describes, so it shouldn't be treated as a complete close of #3808.

A more complete option: remove the tool from the toolset

Passing --disallowedTools AskUserQuestion at spawn cleanly removes the tool rather than denying it:

Check	Result
AskUserQuestion in init.tools[]	0 (gone)
Model emits the tool_use	0
Auto-error tool_result injected	0
permission_denials	[]
Turn outcome	clean end_turn / completed

The model then asks in plain text instead, which the user answers as a normal chat turn (a path that already works). This eliminates the false "waiting" message and the unanswerable card entirely. Tradeoff: OD agents lose structured clarifying questions everywhere — but since headless mode can never answer the structured tool anyway, that's a strict improvement over the current broken card. A fuller fix would also retire the now-dead AskUserQuestionCard UI and the matching system-prompt block.

Reproduction

printf '%s\n' '{"type":"user","message":{"role":"user","content":"Use the AskUserQuestion tool to ask me to choose Red or Blue, then wait."}}' \
  | claude -p --input-format stream-json --output-format stream-json --verbose --permission-mode bypassPermissions
# inspect the JSONL: the tool_use is followed by an auto-injected {is_error:true} tool_result and stop_reason:end_turn.
# now add `--disallowedTools AskUserQuestion` and observe the tool disappears from init.tools[] and is never called.

🤖 Generated by Claude Code on behalf of @cbeaulieu-gt

[lefarcen]

Hey @cbeaulieu-gt — this is a really useful investigation, and it does change the diagnosis in an important way.

The current Claude runtime still assumes --input-format stream-json keeps AskUserQuestion answerable mid-turn, and the system prompt still nudges Claude toward that tool for finite-choice follow-ups. So if headless claude is in fact auto-injecting an error tool_result and ending the turn the way you measured, then #3833 is the right hardening for the false-lock UI race, but not the full fix for #3808.

We should keep this issue open even if #3833 lands. Based on your probe, the next realistic fix path looks runtime-side: stop exposing AskUserQuestion to headless Claude runs (for example via --disallowedTools AskUserQuestion, or an equivalent guard) and let those clarifications fall back to normal chat turns instead of showing an unanswerable card. That also means the eventual fix scope is probably broader than the PR now open — runtime args, the Claude-specific prompt guidance, and whether the current AskUserQuestion card path should stay enabled for this runner at all.

Thanks again for doing the binary-level repro here — this is exactly the kind of evidence that keeps us from closing the issue on a partial fix.

[lefarcen]

@cbeaulieu-gt — quick update: based on your investigation, the team flagged this as a priority bug. The work you shared clarified exactly why the standard UI-only approach doesn't fully resolve things.

The --disallowedTools AskUserQuestion path you tested is the runtime fix needed here. Since you've already done the binary-level verification and have the exact spawn args traced back to apps/daemon/src/runtimes/defs/claude.ts, you'd be the natural person to open the companion runtime PR — the core scope being: add the flag at spawn, remove the system-prompt block nudging headless Claude toward the tool, and retire the dead AskUserQuestionCard path from the daemon's render flow.

PR #3833 handles the UI-side false-lock race and is still under review. This runtime change is what closes the actual user-facing symptom this issue describes.

Would you want to take that on? Feel free to /claim to reserve it — we'll prioritize the review given the priority bump.

[cbeaulieu-gt]

@lefarcen Sure. Ill give it a try. I don' have a full build setup yet but I don't think it should be hard to get a local build so I can test the change.

[cbeaulieu-gt]

/claim