[BUG] Cowork (Windows): AskUserQuestion card is dismissed on its own before the user can answer

Preflight Checklist

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

What's Wrong?

In Cowork mode on Windows, the AskUserQuestion card is sometimes dismissed on its own before the user has a chance to answer it.

From the user's side: the "Asking a question… · 28s" spinner appears, and then the card either never renders or flashes and disappears. Nothing indicates that a question was asked and lost.

From the agent's side, the tool call fails immediately with:

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

The turn then ends with no answer, and the assistant has to re-ask.

Frequency: intermittent. In one working session on 2026-08-06/07 it happened twice out of five AskUserQuestion calls. Both times an identical retry immediately afterwards rendered and worked, which suggests a race rather than a malformed payload — the same "more likely later in long sessions" pattern earlier reporters described.

Prior art, and why this is filed again. The identical agent-side error string is documented in #59707 (Cowork, macOS) — closed as not planned by the stale bot despite 15 👍 and two independent confirmations, one of them a deterministic repro — and in #59024 (VS Code, Windows), also closed. Neighbouring reports: #58750, #59987, #60042, #77549, #81607, and #79584 / #84608 for the "text before the call is not rendered" variant.

What is not yet on file as an open issue is this combination: Cowork on Windows, where the card does render and then vanishes, and where an immediate retry succeeds. That last detail is new evidence — it rules out payload shape as a cause and points at a race in the permission channel setup.

What Should Happen?

The question card stays on screen until the user answers it or explicitly dismisses it. A question is a request for human input, so it should not be cancelled by the client on its own — a person may need minutes to decide.

If the client genuinely has to cancel a pending question (session teardown, reload), then the user should see that it happened, and the assistant should receive a distinguishable reason instead of a generic stream-closed abort, so it can re-ask deliberately rather than guess.

Error Messages/Logs

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

Steps to Reproduce

1. Open the Claude desktop app on Windows 11 and start a Cowork session with a local folder connected.
2. Work in that session for a while. The failures appeared several hours in, after roughly 150 tool calls — not on the first question of the session.
3. Have the assistant emit a few paragraphs of text and then call AskUserQuestion in the same turn, with 2–4 questions, each having 2–4 options. In my case labels and descriptions were in Russian.
4. Watch the question card.

Observed: the "Asking a question…" spinner runs for ~30 seconds, the card disappears without any input, and the assistant reports Tool permission stream closed before response received.

Expected: the card waits for the user.

An immediate retry of the same call rendered normally both times it happened, so a timing/race condition looks more likely than bad input.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.25927.0 (Claude desktop app, Cowork mode — not the CLI)

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Environment

• Claude desktop app 1.25927.0 (MSIX package Claude_1.25927.0.0_x64__pzs8sxrjxfjjc)
• Windows 11 Pro, build 26200
• Cowork mode, local folder connected, session several hours long
• Model: Claude Opus
• "Platform: Other" above means a consumer subscription client, not the API — the template has no option for Cowork.

How this surface differs from the closed reports

| | #59024 | #59707 | this report |
|---|---|---|---|
| Surface | VS Code extension | Cowork desktop | Cowork desktop |
| OS | Windows | macOS | Windows |
| Card renders? | no | no | yes, then disappears |
| User-visible signal | Unhandled case: [object Object] | nothing | spinner, then nothing |
| Retry in same session | — | fails | succeeds |
| State | closed | closed as not planned (stale bot) | — |

The retry succeeding is the part worth chasing: identical payload, same session, seconds apart, different outcome. That is a race in channel setup, not a bad request.

Impact

Low severity, high annoyance. The conversation stalls: the assistant has already committed to asking, the user has nothing to answer, and a turn is wasted. In workflows where the question gates a real action — a deploy, a database migration — each loss costs a full round trip and breaks the rhythm of "ask, confirm, act".

Workaround

Ask questions as plain numbered text in the chat instead of using the card. Chat text does not disappear and can be re-read later; the only thing lost is the structured answer.

Happy to provide session timestamps for log correlation, or to try a smaller reproduction if that would help.