claude-code - 💡(How to fix) Fix [BUG] AskUserQuestion permission channel closes silently on Cowork (macOS) — agent receives "Tool permission stream closed before response received", user sees no popup

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

When the agent invokes the AskUserQuestion tool inside Cowork (Claude desktop app, research preview), the permission channel closes before the user ever sees a popup. The tool call returns Tool permission stream closed before response received agent-side, but no error, popup, or status message reaches the user-facing UI. The conversation deadlocks: the agent is waiting for a response to a question that was never delivered, and the user is waiting for output from an agent that appears frozen. The only user-visible signal is an orange in-progress indicator on the task pill with no forward motion. There is no popup, no error toast, no chat message. The user has no way to know a question was even attempted unless they manually interrupt the agent and ask what's happening. This appears to be the same underlying defect as #59024, but on a different client surface where the error has no rendering path — so it fails silent instead of fails loud. #59024 was closed; this report demonstrates the bug is not VS Code-specific and not Windows-specific. When the permission channel is unavailable, the tool call returns a synchronous error the agent can catch and fall back from immediately (e.g., revert to inline prompt in chat), OR

Error Messages/Logs

User-facing client (Cowork): No error displayed. No popup. No status change. Task pill remains in "in-progress" state indefinitely. Agent-side error returned to the tool call: Error string | Tool permission stream closed before response received | Tool permission stream closed before response received (identical) User-facing symptom | Unhandled case: [object Object] in chat | Silent — no popup, no error, indefinite hang

<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Two unrelated client codebases, two operating systems, identical agent-side error string, identical intermittency pattern. The downstream user-facing symptoms differ only because the two clients have different error-handling paths (VS Code renders the malformed object; Cowork has no surface for it and fails silent). This is one bug in shared infrastructure with two presentation modes.</p> <li class="font-claude-response-body whitespace-normal break-words pl-2">#44435 — <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">PreToolUse</code> hook race producing the same error string (different root cause, but suggests the permission-channel layer has multiple failure modes converging on this opaque error)</li> <li class="font-claude-response-body whitespace-normal break-words pl-2">anthropic-sdk-typescript #854 — 60-second stdin timeout in SDK producing the same error string in a third context</li>

Root Cause

The current behavior — silent stream close with no user-facing surface — is the worst of all worlds because it produces an indefinite deadlock that neither party can recover from without manual intervention.

Code Example

User-facing client (Cowork): No error displayed. No popup. No status change. Task pill remains in "in-progress" state indefinitely.
Agent-side error returned to the tool call:
Tool permission stream closed before response received
(Cowork is a consumer client; the user does not have access to bundled CLI logs or structured stderr the way #59024's reporter did. Happy to provide session details to anyone with server-side log access — session occurred [INSERT DATE/TIME UTC] on account associated with this GitHub address.)
RAW_BUFFERClick to expand / collapse

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?

When the agent invokes the AskUserQuestion tool inside Cowork (Claude desktop app, research preview), the permission channel closes before the user ever sees a popup. The tool call returns Tool permission stream closed before response received agent-side, but no error, popup, or status message reaches the user-facing UI. The conversation deadlocks: the agent is waiting for a response to a question that was never delivered, and the user is waiting for output from an agent that appears frozen. The only user-visible signal is an orange in-progress indicator on the task pill with no forward motion. There is no popup, no error toast, no chat message. The user has no way to know a question was even attempted unless they manually interrupt the agent and ask what's happening. This appears to be the same underlying defect as #59024, but on a different client surface where the error has no rendering path — so it fails silent instead of fails loud. #59024 was closed; this report demonstrates the bug is not VS Code-specific and not Windows-specific.

What Should Happen?

Either:

The AskUserQuestion popup actually renders in the Cowork UI and waits for user input, OR When the permission channel is unavailable, the tool call returns a synchronous error the agent can catch and fall back from immediately (e.g., revert to inline prompt in chat), OR The agent harness auto-falls-back to an inline chat prompt when the popup channel fails, with no agent-side intervention required.

The current behavior — silent stream close with no user-facing surface — is the worst of all worlds because it produces an indefinite deadlock that neither party can recover from without manual intervention.

Error Messages/Logs

User-facing client (Cowork): No error displayed. No popup. No status change. Task pill remains in "in-progress" state indefinitely.
Agent-side error returned to the tool call:
Tool permission stream closed before response received
(Cowork is a consumer client; the user does not have access to bundled CLI logs or structured stderr the way #59024's reporter did. Happy to provide session details to anyone with server-side log access — session occurred [INSERT DATE/TIME UTC] on account associated with this GitHub address.)

Steps to Reproduce

  1. Open a new Cowork session on macOS.
  2. Give the agent a multi-step task complex enough that it will plausibly want clarification mid-execution.
  3. Wait for the agent to invoke AskUserQuestion. 3b. User wants to paste screenshots to answer questions instead of choosing one of the prompts. 3c. User is typing a long description in the the "other" field for a text line and the popup times out. OR
  4. Observe: no popup renders. Task pill shows orange in-progress indicator.
  5. Agent receives Tool permission stream closed before response received and either retries (silently, also failing) or sits indefinitely.
  6. Conversation can only proceed if the user interrupts with a plain chat message ("status?" / "what are you waiting on?") which causes the agent to abandon the tool call and use inline prompts for the rest of the session.

Intermittency pattern matches #59024: more likely in longer sessions and after earlier AskUserQuestion calls succeeded in the same session.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

Unknown — intermittent regression. Same account has had successful AskUserQuestion calls earlier in the same session.

Claude Code Version

n/a i use cowork.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]"><strong>Cross-surface evidence the bug is in shared permission-channel infrastructure, not in any specific client:</strong></p> <div class="overflow-x-auto w-full px-2 mb-6">   | #59024 (original) | This report -- | -- | -- Surface | VS Code extension | Cowork desktop app OS | Windows | macOS Version | Claude Code 2.1.92 | Cowork research preview (current) Tool | AskUserQuestion | AskUserQuestion Error string | Tool permission stream closed before response received | Tool permission stream closed before response received (identical) User-facing symptom | Unhandled case: [object Object] in chat | Silent — no popup, no error, indefinite hang Intermittency | Long sessions, after previous stalls | Long sessions, after previous stalls </div> <p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Two unrelated client codebases, two operating systems, identical agent-side error string, identical intermittency pattern. The downstream user-facing symptoms differ only because the two clients have different error-handling paths (VS Code renders the malformed object; Cowork has no surface for it and fails silent). This is one bug in shared infrastructure with two presentation modes.</p> <p class="font-claude-response-body break-words whitespace-normal leading-[1.7]"><strong>Related issues worth cross-referencing:</strong></p> <ul class="[li_&amp;]:mb-0 [li_&amp;]:mt-1 [li_&amp;]:gap-1 [&amp;:not(:last-child)_ul]:pb-1 [&amp;:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3"> <li class="font-claude-response-body whitespace-normal break-words pl-2">#59024 — VS Code/Windows surface of this bug (closed)</li> <li class="font-claude-response-body whitespace-normal break-words pl-2">#44435 — <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">PreToolUse</code> hook race producing the same error string (different root cause, but suggests the permission-channel layer has multiple failure modes converging on this opaque error)</li> <li class="font-claude-response-body whitespace-normal break-words pl-2">anthropic-sdk-typescript #854 — 60-second stdin timeout in SDK producing the same error string in a third context</li> </ul> <p class="font-claude-response-body break-words whitespace-normal leading-[1.7]"><strong>Proposed labels:</strong> <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">area:permissions</code>, <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">bug</code>, <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">has repro</code>, <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">platform:cowork</code> (or equivalent — not <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">platform:vscode</code>), <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">cross-platform</code></p>

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] AskUserQuestion permission channel closes silently on Cowork (macOS) — agent receives "Tool permission stream closed before response received", user sees no popup