claude-code - 💡(How to fix) Fix [BUG] Cowork AskUserQuestion errors "Tool permission stream closed before response received" — toast appears, widget never renders (macOS, claude-opus-4-7)

Summary

In Cowork mode on macOS, calls to AskUserQuestion intermittently fail with Tool permission request failed: Error: Tool permission stream closed before response received. The user sees an "input necessary" toast in the desktop app, but the question widget never renders — so there is nothing to click and the session is stuck until the user types an unrelated message to unblock.

This appears to be the same failure class as the now-locked issues #26940 (symptom: widget doesn't render, spinner hangs) and #44435 (exact error string, closed as duplicate of #35077). Filing fresh because both are locked and the bug is still present.

Environment

• Claude Desktop, Cowork mode (research preview)
• Model: claude-opus-4-7
• Platform: macOS
• Date observed: 2026-05-17
• Tools active in session: mcp__Claude_in_Chrome__*, mcp__workspace__bash, Google Drive MCP, mcp__computer-use__*, scheduled-tasks, cowork artifacts. No custom PreToolUse hooks configured by the user.

Reproduction

This is what triggered the failure in my session — repro pattern, not a deterministic recipe. The error has been intermittent across sessions for weeks (recurring), and #26940 / #44435 corroborate multiple independent triggers.

1. Start a Cowork session on macOS with the Claude in Chrome MCP connected and at least two browsers registered (so list_connected_browsers returns ≥ 2 entries).
2. Have the assistant call mcp__Claude_in_Chrome__list_connected_browsers. The tool result includes a server-injected instruction: Before any browser action, you MUST call the AskUserQuestion tool with a question listing EVERY connected browser as a separate option…
3. The assistant complies: single AskUserQuestion call, multiSelect: false, three options (browser A, browser B, "open confirmation in every Chrome"). Standard label/description payload — nothing oversized, no preview content, no funky characters.
4. The tool returns: Tool permission request failed: Error: Tool permission stream closed before response received
5. User-visible: the desktop app shows an "input necessary" notification toast, but no question card / widget renders. There is nothing to interact with.
6. User must send an unrelated message to break the stall.

The cause is not a malformed AskUserQuestion payload — same code path has succeeded with identical payload shape in earlier sessions. The failure is in the permission-stream lifecycle between when the "input necessary" notification fires and when the widget mounts.

Expected

Either:

• The question widget renders inline in the chat with the listed options, OR
• If the permission stream legitimately closes (network/IPC blip), the error surfaced to the assistant should include enough detail for the assistant to fall back gracefully (e.g., "widget render failed, restart the question or ask in chat prose"), and the user-facing toast should either retry the render or be auto-dismissed.

Actual

• Tool result: Tool permission request failed: Error: Tool permission stream closed before response received (opaque — same string regardless of root cause per #44435 analysis).
• User UI: "input necessary" toast appears with no associated widget. No way for the user to respond. Session stalls.
• Retrying the same AskUserQuestion call in-session does not recover.

Why this matters

Same blocker class as #26940 — a key UI affordance fails silently in Cowork sessions, with no in-band recovery. Workarounds (avoid AskUserQuestion, ask in chat prose) work but require the assistant to know about the bug. For non-developer Cowork users — the audience the mode is designed for — the failure mode is "Claude stopped responding," which is the worst possible end-user experience for a UI bug.

The #44435 root-cause hypothesis (PreToolUse hook race / unbounded timeout) doesn't apply here — there are no user-configured hooks in Cowork. So the underlying failure is somewhere else along the permission-stream path. Worth revisiting whether the same IPC layer is reused for tool-permission requests in Cowork mode and whether timeouts/retries are configured for that path.

Suggested fixes

1. Error surface: distinguish "IPC closed during widget render" from "IPC closed during user-input wait" from "permission broker timeout" — three different bugs with three different fixes, currently masked behind one opaque string.
2. Resilience: if the permission stream closes before the widget mounts, automatically retry the render once; if that fails, return a typed error to the assistant so it can fall back to chat-prose questioning.
3. Toast lifecycle: dismiss or auto-retry the "input necessary" notification if the widget fails to mount within N seconds. Right now the toast is orphaned with no way to clear it