claude-code - 💡(How to fix) Fix [BUG] Cowork: User messages remain in pulsating in-flight state after session-switch — regression / incomplete-fix variant of the #26805 / #26921 / #44776 cluster (macOS, May 2026)

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?

Cowork UI bug, macOS, Claude Desktop, observable for approximately two months as of 2026-05-15.

Trigger: send a follow-up message in session A while Claude is mid-response; switch to session B; return to session A. The follow-up user messages remain in the pulsating in-flight animation indefinitely, even after Claude's response completes in the background and the composer returns to "Write a message…" (i.e., the session is responsive and Claude is not in-flight). The pulsating animation persists for the lifetime of the session.

This is a different visible state than #44776 (faded/greyed-out static rendering with assistant content missing). Here the assistant response is present and complete; only the user-message UI state is stuck on the in-flight visual.

This appears to be a regression or incomplete fix of the bug family tracked in:

• #26805 "Cowork UI: Responses not rendering until user types" — fixed 2026-02-24, locked
• #26921 "Cowork UI freezes mid-response; other chat threads go blank" — closed
• #29793 "Cowork: Conversation rollback/loss when switching to settings or menus" — closed as duplicate
• #44776 "Cowork UI: Task responses vanish from chat after switching between tasks" — closed as duplicate (closest specific symptom sibling)
• #34708 "Chat stream display corruption: lost responses and stacked messages"
• Anthropic April 23 postmortem: v2.1.116 (April 20) fix wave addressed related Cowork message-delivery regressions

The pulsating-user-message variant persists past both fix waves. Reporter started observing the symptom around 2026-03-15 (between the Feb 24 fix and the April 20 fix wave) and continues observing it as of 2026-05-15 (one month after the April fix wave).

What Should Happen?

After Claude completes the in-flight response, every queued or sent user message in the affected session should transition to its settled "delivered" rendering. Returning to a backgrounded session should re-hydrate message state from authoritative server-side delivery status, not from a cached client-side state object.

Error Messages/Logs

Inspected ~/Library/Logs/Claude/ on macOS (4 files: main.log 124k lines, claude.ai-web.log 752 lines, coworkd.log, cowork_vm_node.log). 

Direct evidence for the pulsating bug is absent from local logs. The Electron main process logs 405 LocalAgentModeSessions.sendMessage calls in the captured window (2026-05-12 to 2026-05-15) with zero matching messageComplete / streamingComplete / messageReceived / cancelMessage / stop / abort events. The send path is logged; the completion path is not logged anywhere on disk. There are zero WebSocket close/reopen events for the chat session, zero visibilitychange / focus / blur / session-switch entries, and zero rehydration / cache-load entries. The 18 "disconnect" hits in main.log are all ERR_INTERNET_DISCONNECTED during an unrelated offline stretch; the 28 hits in cowork_vm_node.log are all "[VM] Guest disconnected during graceful quit" VM-lifecycle events.

Indirect evidence — sibling reconciliation bug in the same code path. claude.ai-web.log contains 534 instances of this warning:

[warn] [LOCAL_SESSION] Subagent parent not found for user message - possible out of order processing {"parentToolUseId":"toolu_XXX","uuid":"YYY"}

First occurrence in captured window: 2026-05-07 12:11:19. Most recent: 2026-05-13 22:24:46. 94 of the 534 occurrences fall in the last three captured days (post v2.1.116 April 20 fix wave). The same uuid values recur dozens of times, indicating the renderer repeatedly retries processing the same out-of-order messages.

The warning fires when the renderer receives a user message whose parentToolUseId references a tool-use it hasn't received yet, i.e. the renderer's local view of the conversation tree is out of sync with server event ordering. This is the same [LOCAL_SESSION] code path that holds per-message UI state in Cowork mode. The renderer has an active reconciliation failure in the exact code path responsible for the pulsating-state bug, with 94 fresh instances post the most recent fix wave.

Observability gap. The renderer logs Subagent parent not found warnings but logs nothing else from the message-state pipeline. No log signal for: message-status transitions (in-flight to delivered), session-switch / focus / blur / visibilitychange events, server-side streaming-complete reception, or session rehydration. Adding instrumentation to the [LOCAL_SESSION] code path would let this whole bug family be diagnosed from local logs without internal reproduction.

The four log files are staged locally and available on request: main.log, claude.ai-web.log, coworkd.log, cowork_vm_node.log.

Steps to Reproduce

1. Open Claude Desktop → Cowork.
2. Start a session ("Session A") and prompt Claude with a request that takes meaningful wall-clock time.
3. While Claude is mid-response (in-flight indicator active), send one or more follow-up user messages in Session A.
4. Before Claude completes, switch to a different Cowork session ("Session B").
5. Wait long enough for Session A's response to complete in the background.
6. Switch back to Session A.

Observed: Follow-up user messages from step 3 are rendered with the pulsating in-flight animation, and they remain in that state for the remainder of the session's lifetime. The composer shows "Write a message…" confirming Claude is not in-flight.

Frequency: Consistent when the trigger sequence is followed. Has been observable since approximately 2026-03-15.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

Claude 1.7196.0 (2dbd78) 2026-05-12T05:34:40.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Regression / incomplete-fix framing (please read before deduping).

This is not a duplicate of any open issue. It IS a recurrence of the symptom cluster tracked in the following issues, all of which are closed or fixed:

• #26805 "Cowork UI: Responses not rendering until user types" — fixed 2026-02-24, locked
• #26921 "Cowork UI freezes mid-response; other chat threads go blank until app restart" — closed
• #29793 "Cowork: Conversation rollback/loss when switching to settings or menus" — closed as duplicate
• #44776 "Cowork UI: Task responses vanish from chat after switching between tasks — backend completes, frontend drops render" — closed as duplicate (closest specific symptom sibling)
• #34708 "Chat stream display corruption: lost responses and stacked messages in long/multi-session usage"
• Anthropic April 23 postmortem (https://www.anthropic.com/engineering/april-23-postmortem) documents v2.1.116 (2026-04-20) addressing related Cowork message-delivery regressions

Reporter first observed this specific symptom approximately 2026-03-15, between the #26805 fix (Feb 24) and the v2.1.116 fix wave (April 20). The symptom continues as of 2026-05-15, one month after the most recent fix wave. Either the fix waves missed this variant or the bug regressed after them.

Distinguishing visible symptom from #44776. In #44776 the user messages render statically faded/greyed-out and the assistant response is missing. In this report, user messages remain in the pulsating in-flight animation (still actively animating) and the assistant response is present and complete. Same root cause family; different surface state.

Hypothesis on root cause. Per-message in-flight state is set when the user sends a message while a prior response is still streaming. The clear transition fires on a streaming-complete event that only the foregrounded session's WebSocket subscription listens for. When the user switches sessions, the originating session's subscription is suspended (or backgrounded by Electron's renderer process management), so the clear event is missed. On return, the renderer re-hydrates from a cached client-side state object rather than re-querying the server for per-message delivery status, so the stale in-flight flag is preserved. This is consistent with the renderer's documented LOCAL_SESSION parent-toolUse-not-found reconciliation failures (see Error Messages/Logs).

Workaround. Not confirmed. Untested candidates: closing and reopening the session, quitting and relaunching Claude Desktop, sending another message in the affected session to force a re-render (the workaround that worked for #26921 and #44776).

Reporter context. Heavy parallel-Cowork user running 5-10 concurrent sessions for asynchronous IP-capture workflows. The send-message-mid-stream + session-switch pattern is a routine workflow, not an edge case. Approximately two months of consistent reproduction across captain dispatches and parallel-session juggling.

Screenshot. Three stacked user messages in pulsating animation at the bottom of an active Cowork session ("F1 Capt. - Kernel v2 Absorption Captain Kickoff") while the composer reads "Write a message…" (Claude not in-flight). Attached.