[BUG] Cowork (macOS Desktop 1.9659.1): chat UI enters persistent broken state until app restart — messages stuck as ghost bubbles, AskUserQuestion never renders and is auto-denied (one confirmed trigger: webview connectivity loss)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (closest matches are Cowork API-connection issues like #25205, but none describe the never-reconnecting chat webview / auto-denied AskUserQuestion)
• [x] This is a single bug report — two visible symptoms, but logs show one single root cause (evidence below)
• [x] I am using the latest version of the Claude Desktop app (1.9659.1, macOS)

What's Wrong?

In Cowork mode on the macOS Desktop app, the embedded claude.ai webview that renders the chat intermittently loses network connectivity and never re-establishes it (no auto-reconnect/resync). The agent session itself (VM / host-loop side) keeps running fine the whole time. This one failure produces two user-visible symptoms that always co-occur:

Symptom 1 — "ghost" stuck messages. Messages sent while the webview is in this state ARE delivered to the agent (main process logs sendMessage, the agent processes and answers them), but the optimistic gray bubble at the bottom of the conversation is never confirmed/replaced. It stays there forever, and the rest of the conversation keeps rendering on top of it. Only an app restart clears it.

Symptom 2 — AskUserQuestion dialog never appears, then auto-denied. When the agent calls AskUserQuestion, the main process emits the tool permission request, but the UI never renders the question dialog. The request stays pending invisibly. When the user eventually stops the session (or sends a new message after stopping), the bridge auto-denies the pending request — the question card then displays as failed ("Échec"), and the agent receives a deny + "Continue from where you left off" instead of the user's answer. My logs show 10 occurrences of this auto-deny in ~4 days, across multiple different Cowork sessions.

Restarting the app fixes both symptoms — until the next occurrence. This happens multiple times per day and forces regular app restarts.

What Should Happen?

• The chat webview should detect lost connectivity and automatically reconnect/resync its state with the session transcript (which is correct on disk — a restart proves it).
• A pending AskUserQuestion/permission request should be rendered once the UI is back, not silently dropped and auto-denied.
• Sent-message bubbles should reconcile with the transcript instead of staying in "pending" state forever.

Error Messages/Logs

Timeline of one full incident (2026-06-04, main.log, paths redacted). Note the user message at 15:33:21 (this is one of the bubbles that got stuck), the AskUserQuestion emitted at 15:34:09 that never rendered, the connectivity errors, and the auto-deny at session stop:

2026-06-04 15:33:21 [info] LocalAgentModeSessions.sendMessage: sessionId=local_38031a83-248c-4722-ade7-10b9b81b551d, messageLength=196, imageCount=0, fileCount=0, widgetStates=0
2026-06-04 15:34:09 [info] Emitted tool permission request db976096-45a5-4641-99cd-c5323fd2f919 for AskUserQuestion in session local_38031a83-248c-4722-ade7-10b9b81b551d
2026-06-04 15:35:25 [error] [growthbook] network error: Error: net::ERR_CONNECTION_CLOSED
2026-06-04 15:35:29 [info] LocalAgentModeSessions.stop: sessionId=local_38031a83-248c-4722-ade7-10b9b81b551d
2026-06-04 15:35:29 [info] Bridge resolving permission db976096-45a5-4641-99cd-c5323fd2f919: behavior=deny (tool: AskUserQuestion)
2026-06-04 15:35:35 [info] LocalAgentModeSessions.sendMessage: sessionId=local_38031a83-248c-4722-ade7-10b9b81b551d, messageLength=18, ...
2026-06-04 15:35:35 [warn] [LocalAgentModeSessionManager] /enabled-state prefetch failed; defaulting to all-enabled: net::ERR_CONNECTION_CLOSED
2026-06-04 15:36:09 [error] [EventLogging] POST threw: Error: net::ERR_CONNECTION_CLOSED
2026-06-04 15:37:19 [info] Emitted tool permission request 54c016dc-a65c-4fd0-a1a7-dc65729334d3 for AskUserQuestion in session local_38031a83-248c-4722-ade7-10b9b81b551d
2026-06-04 15:40:38 [info] LocalAgentModeSessions.stop: sessionId=local_38031a83-248c-4722-ade7-10b9b81b551d
2026-06-04 15:40:38 [info] Bridge resolving permission 54c016dc-a65c-4fd0-a1a7-dc65729334d3: behavior=deny (tool: AskUserQuestion)

Renderer side (claude.ai-web.log) — fetch storm starting at exactly the same moment, 12 failures in 80s, bracketing the emitted permission request. After this the webview never recovers:

2026-06-04 15:34:14 [error] [REACT_QUERY_CLIENT] QueryClient error: {"name":"TypeError","message":"Failed to fetch","stack":"TypeError: Failed to fetch\n    at a (https://assets-proxy.anthropic.com/claude-ai/v2/assets/v1/cc8728789-DTwlKzkB.js:2:24096) ...
(repeated 12x between 15:34:14 and 15:35:35)

Control case — same flow a few hours earlier with a healthy webview, where the dialog rendered and everything worked:

2026-06-04 12:16:56 [info] Emitted tool permission request 506a130d-2516-4fc9-8cb0-07f10f75f068 for AskUserQuestion in session local_d24b5abb-...
2026-06-04 12:20:53 [info] LocalAgentModeSessions.respondToToolPermission: requestId=506a130d-2516-4fc9-8cb0-07f10f75f068, decision=once, hasUpdatedInput=true
2026-06-04 12:20:53 [info] Received permission response for 506a130d-2516-4fc9-8cb0-07f10f75f068: once (tool: AskUserQuestion)

All AskUserQuestion auto-denies in my logs (every one of them = a question the user never saw):

2026-05-31 22:27:20 Bridge resolving permission c3207f71-...: behavior=deny (tool: AskUserQuestion)
2026-06-03 04:43:16 Bridge resolving permission 91053909-...: behavior=deny (tool: AskUserQuestion)
2026-06-03 14:34:28 Bridge resolving permission 39141ad3-...: behavior=deny (tool: AskUserQuestion)
2026-06-03 14:59:24 Bridge resolving permission 449211e5-...: behavior=deny (tool: AskUserQuestion)
2026-06-04 00:52:50 Bridge resolving permission 26fdb102-...: behavior=deny (tool: AskUserQuestion)
2026-06-04 00:54:29 Bridge resolving permission 23b6aff7-...: behavior=deny (tool: AskUserQuestion)
2026-06-04 01:38:46 Bridge resolving permission c134a9ee-...: behavior=deny (tool: AskUserQuestion)
2026-06-04 01:40:14 Bridge resolving permission 51132ba6-...: behavior=deny (tool: AskUserQuestion)
2026-06-04 15:35:29 Bridge resolving permission db976096-...: behavior=deny (tool: AskUserQuestion)
2026-06-04 15:40:38 Bridge resolving permission 54c016dc-...: behavior=deny (tool: AskUserQuestion)

Related error also present in main.log when the stream closes with requests still pending:

error: Tool permission stream closed before response received

Steps to Reproduce

Not deterministic on demand — it follows a connectivity break while a Cowork conversation is open (observed triggers: network drop; the overnight occurrences are consistent with machine sleep). Best reproduction:

1. Open a Cowork conversation on macOS Desktop and let the agent run.
2. Break connectivity to anthropic endpoints (sleep the Mac or cut the network) until the webview's requests fail (renderer logs TypeError: Failed to fetch, main process logs net::ERR_CONNECTION_CLOSED).
3. Restore the network. The webview does not recover on its own.
4. Send a message → it appears as a gray "pending" bubble at the bottom and stays there forever, even though the agent receives and answers it (conversation renders over the ghost bubble).
5. Have the agent call AskUserQuestion → no dialog ever appears. Stop the session → the question card shows as failed; log shows Bridge resolving permission …: behavior=deny (tool: AskUserQuestion).
6. Restart the app (or reload the window) → UI rebuilds from the transcript and everything is correct again.

Claude Model

Opus

Is this a regression?

I don't know

Claude Code Version

Claude Desktop app 1.9659.1 (macOS, Cowork mode; bundled host loop / agent SDK — not the standalone CLI)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other (Claude Desktop app — Cowork, not a terminal)

Additional Information

Why this is one issue and not two: both symptoms strictly co-occur and are bracketed by the same renderer connectivity-loss window — e.g. the fetch storm 15:34:14→15:35:35 exactly covers the stuck message sent at 15:33:21 and the AskUserQuestion emitted at 15:34:09. The session/agent layer is provably healthy during incidents (messages delivered, tools executed). The defect is in the chat webview's lost-connection recovery; fixing the reconnect/resync should fix both symptoms at once.

Impact: requires a full app restart several times a day; AskUserQuestion is effectively unusable (users learn to tell the agent "don't use AskUserQuestion, ask in plain text"), and the agent silently receives denies for questions the user never saw, which degrades agent behavior.

Happy to provide fuller logs privately on request.