claude-code - 💡(How to fix) Fix [BUG] Headless mode (`-p --output-format stream-json`) breaks AskUserQuestion handling — model continues on assumptions instead of stopping

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

In headless mode (-p --output-format stream-json), when the model decides to ask clarifying questions via AskUserQuestion, it does not stop and yield control. Instead it treats its own questions as "dismissed" by the user and continues working based on its own assumptions.

This breaks an iterative headless pipeline where each iteration is expected to halt when the model needs input, so that an operator (or an external system) can collect the answers and feed them back as context in the next iteration.

Example of the broken behavior:

The user dismissed the clarifying questions. I'll produce a Draft specification because several scope/payload-shape decisions need to be confirmed before this can be marked Ready. I'll document my reasonable assumptions and list the open questions explicitly.

On 2.1.158 the behavior is "softer" but still wrong — instead of cleanly stopping, the model re-prompts/nudges itself:

It looks like you skipped the questions. To move forward, I still need your preferences on at least the most critical point — #4 (ID leakage in event payloads), since the architecture depends on it. Let me rephrase: can you answer at least these four points in free form, or click the options in the form above?

What Should Happen?

If the model has questions it cannot answer on its own, it should ask them and then STOP the turn, yielding control instead of continuing on assumptions.

In a headless iterative pipeline this is essential: the operator (or an external system) is responsible for collecting the answers and passing them back as context on the next -p invocation. The model must not assume that unanswered questions were "dismissed" and must not fabricate answers to proceed.

Expected:

1. Model emits its clarifying questions (AskUserQuestion) in the stream-json output.
2. No work is performed based on assumed answers.
3. On the next iteration, the operator supplies the answers as context and the model continues.

Error Messages/Logs

No error is emitted — this is a behavioral issue, not a crash. The problem is the absence of a clean stop: the model continues the turn after its own questions instead of halting.

Steps to Reproduce

1. Run Claude Code in headless streaming mode:

   claude -p --model <MODEL> \
     --output-format stream-json \
     --verbose

1. Provide a task whose scope is intentionally underspecified, with a prompt that asks the model to clarify open decisions before producing a final/"Ready" result (e.g. a specification task with several unconfirmed scope/payload-shape decisions).

2. Do NOT answer / there is no interactive party to answer (headless pipeline).

Observed: the model states that the user "dismissed" the questions (or "skipped" them) and continues producing a Draft based on its own assumptions, instead of stopping and waiting for answers to be supplied in the next iteration.

settings.json used:

{
  "enableAllProjectMcpServers": true,
  "sandbox": { "enabled": false },
  "permissions": {
    "defaultMode": "bypassPermissions",
    "allow": ["Bash","Edit","Read","WebFetch","WebSearch","Write"],
    "deny": [],
    "ask": []
  }
}

Workaround that confirms the cause: disabling AskUserQuestion restores the expected behavior — the model stops instead of continuing on assumptions.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.131

Claude Code Version

2.1.158

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Xterm

Additional Information

Version / model matrix:

This points to a regression introduced between 2.1.131 and 2.1.140.

Use case / why this matters:

We run an iterative headless pipeline. Each -p iteration is expected to halt whenever the model needs input. An external operator/system then collects the answers and feeds them back as context on the next iteration. The current behavior — assuming questions were "dismissed" and continuing on fabricated assumptions — breaks this loop, because there is no clean stop and no reliable signal in stream-json that the turn ended specifically because the model is waiting on the user.

Workaround:

disabling AskUserQuestion restores the expected "stop" behavior.

Requested fix:

In headless/non-interactive (-p) mode, when the model raises AskUserQuestion (or otherwise needs clarification), the turn should end cleanly with a machine-detectable "awaiting user input" signal, instead of treating the questions as dismissed and continuing on assumptions.