claude-code - 💡(How to fix) Fix [BUG] AskUserQuestion fails with "Tool permission stream closed before response received" when dispatched in a parallel batch alongside other tool calls

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?

On 2026-05-16, a call to the built-in AskUserQuestion tool in Cowork mode returned an error mid-batch while several other tool calls dispatched in the same parallel batch succeeded. The interactive multi-choice prompt never rendered for the user — they saw nothing on screen and could not respond. The other tool calls in the same batch (Edit, TaskCreate, TaskUpdate, Agent) all completed normally.

The five-call batch contained, in order: Edit (succeeded), TaskCreate (succeeded), TaskUpdate (succeeded), Agent dispatched on a long-running general-purpose task (succeeded after 199,987 ms), and AskUserQuestion (failed with the error in the Error Messages field below). AskUserQuestion returned its error immediately, not after a wait — which is informative for hypothesis ordering (see Additional Information).

Payload submitted to AskUserQuestion: one question, four options, multiSelect: false. Total payload ~1.5 KB. Schema-clean: no nesting, no special characters, valid JSON shape, conforms to the documented tool schema. Content has been generalized for this report to remove user-specific context; the structural shape (1 question, 4 options, label and description length bands) is preserved because the failure is hypothesized to be about batching and shape rather than content.

Note on environment: this bug occurred in Cowork mode within the Claude desktop app (research preview), NOT in the Claude Code CLI. Filing in this repository because it serves as the issue tracker for both products.

What Should Happen?

The AskUserQuestion widget should render in the user's chat, the agent loop should pause awaiting the user's selection, and the answer should return to the model. The sibling tool calls in the same batch should either complete in parallel as usual, OR the system should reject the batch at validation time with a clear, model-readable error stating that AskUserQuestion must be dispatched without parallel siblings.

Either resolution is acceptable. The current behavior — silent UI no-show plus a vague stream-closed error returned only to the model — is the bug.

Error Messages/Logs

Tool permission request failed: Error: Tool permission stream closed before response received

Steps to Reproduce

1. Open Cowork mode in the Claude desktop app.
2. In a single response (single function_calls block), dispatch five tool calls in parallel:
   1. Edit — any file edit
   2. TaskCreate — any task creation
   3. TaskUpdate — set the newly created task to in_progress
   4. Agent — dispatch a general-purpose subagent on a long-running research task (3+ minutes)
   5. AskUserQuestion — a single question with 4 options, multiSelect: false
3. Observe that the first four calls succeed and AskUserQuestion returns the error above immediately.
4. Observe that no question widget renders in the user's chat.

Suggested follow-up tests for the investigator (to distinguish hypotheses):

• Repeat AskUserQuestion alone in a batch with the same payload. If it succeeds, parallel-batching is the cause.
• Repeat AskUserQuestion batched with only Read/Edit calls (no Agent, no long-runners). If it still fails, the issue is parallel-batching in general, not Agent specifically.

Confirmed working as a positive control: an AskUserQuestion call dispatched alone in its own batch (after the failure) rendered correctly and returned the user's answer. This is empirical support for the parallel-batching hypothesis.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

N/A — first occurrence

Claude Code Version

N/A — Cowork desktop app, not Claude Code CLI. Cowork client version was not visible from inside the session; available on request via private channel.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Hypotheses for the cause, ordered by what I'd investigate first:

H1 — AskUserQuestion is incompatible with parallel Agent calls in the same batch. AskUserQuestion opens an interactive permission stream to the client UI. Agent calls run in the orchestration layer. If the permission stream is closed while the Agent is in flight, this is the error signature you would see.

H2 — AskUserQuestion requires being the sole tool call in its batch (no parallel siblings at all). Some interactive tools enforce exclusive batches. The Cowork system prompt does not document this, but the implementation may enforce it. The fact that the error returns immediately, not after the Agent's ~200 second runtime, is more consistent with H2 than with H1. Subsequent positive control (sole-batched AskUserQuestion rendering correctly later in the same session) supports H2.

H3 — Permission stream timeout independent of Agent. Possible, but the immediate-return signature argues against this.

H4 — A prior tool call in the session poisoned the permission channel. Earlier in the session, an mcp__cowork__allow_cowork_file_delete request was granted and used cleanly. Unlikely but worth ruling out.

H5 — Payload size or content. Schema-clean, ~1.5 KB. Lowest probability.

Suggested fix direction:

• (A) Enforce sole-batching for AskUserQuestion: reject batches that include it alongside other tools, returning a clear validation error to the model so it can retry the question alone in its next response, OR
• (B) Queue AskUserQuestion to render after sibling tools resolve: buffer the question widget until the parallel batch completes, then render and pause the agent loop.

Whichever direction is taken, the Cowork system prompt's ask_user_question_tool section should be updated to document the constraint, and the error returned to the model when the constraint is violated should clearly state the rule rather than the current "stream closed before response received" message.

Workaround in current builds: do not batch AskUserQuestion with any other tool calls. Send it alone in its own response, after any prerequisite work has completed.

Session metadata: a session identifier exists for this occurrence and can be provided privately to engineering via [email protected] for log correlation. It has been omitted from this public issue.

Notes on the preflight checklist for this issue

The third preflight item ("I am using the latest version of Claude Code") has been left unchecked because this bug occurred in Cowork mode within the Claude desktop app, not in the Claude Code CLI. Filing here because this repository serves as the issue tracker for both products. The Cowork client version was not visible from inside the session.

Related

• #60036 — a companion feature request for a PII-scrub attestation preflight in every issue template in this repo. That request came out of the same Cowork session that produced this bug.