[BUG] Cowork UI: Task responses vanish from chat after switching between tasks — backend completes, frontend drops render

Resolved 💬 3 comments Opened Apr 7, 2026 by jjsteffe Closed Apr 11, 2026

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?

When switching between Cowork tasks while Claude is actively generating a response (particularly file creation workflows), returning to the original task shows user messages in a faded/greyed-out state but Claude's response content is completely absent from the UI.

The backend processes successfully — generated files appear in the workspace folder structure, session files update, CLAUDE.md changes persist — but the response text, file cards, and source links never render in the chat panel.

This is 100% reproducible when switching away during active generation. If the response completes before switching, content mostly persists.

Key observations from screenshots:

  • User message bubbles: visible but faded/greyed (reduced opacity)
  • Claude response bubbles: completely missing — not collapsed, not scrolled off, just absent
  • Copy/retry action icons sometimes float with no content above them
  • Loading spinner (Anthropic asterisk) may appear at bottom despite processing being complete
  • "Show more" collapse indicators may appear with no expandable content

Comparison with working state: When staying focused on a task through completion, responses render normally — full dark text, file attachment cards, source links, no fading on user messages.

This appears to share a root cause with several existing issues:

  • #26921 — "Switching to any other Cowork task renders it completely blank" (identical symptom; reporter confirmed sending a message forces re-render)
  • #26805 — "Responses not rendering until user types" (same re-render trigger workaround)
  • #40142 — Dispatch variant where TypeError in renderer prevents response display
  • #36131 — Scheduled tasks require active focus to fire (same focus-dependency pattern)

The common thread: the Cowork UI renderer is coupled to active focus/visibility state, causing any content generated while the panel is not the foreground view to be dropped or never mounted to the DOM.

What Should Happen?

Cowork task responses should fully render and persist in the chat UI regardless of whether the user switches to another task during generation. When returning to a previously active task:

  1. Claude's completed response should be visible in full (text, file cards, links, formatting)
  2. User message bubbles should display at normal opacity (not faded/greyed)
  3. If generation is still in progress, the streaming response should resume rendering from where it left off
  4. No user interaction (sending a message, scrolling, resizing) should be required to trigger display of already-completed responses

This is critical because Cowork's primary value proposition is asynchronous task execution — "give Claude a task and go do other things." File creation workflows (Cowork's flagship use case) inherently take time, making task-switching the expected user behavior, not an edge case.

Error Messages/Logs

No error messages visible in the UI. The failure is silent — no error state, no toast, 
no "something went wrong" banner. The response area simply remains empty.

No access to Electron renderer console logs from the Desktop app UI. If the engineering 
team can point me to the log file location (e.g., claude.ai-web.log), I'm happy to 
reproduce and attach renderer logs.

Note: Issue #40142 captured the likely underlying error from logs:
  TypeError: Cannot read properties of undefined (reading 'includes')
  [REACT_QUERY_CLIENT] QueryClient error: Error: Not found
These repeat on every render cycle when the affected panel regains focus.

Steps to Reproduce

  1. Open Claude Desktop app → navigate to Cowork
  2. Start a task that involves file creation (e.g., "Create a skill package with SKILL.md, reference files, and examples")
  3. While Claude is actively generating the response (spinner visible, streaming in progress), click on a different Cowork task in the sidebar
  4. Allow 30-60 seconds for the original task to complete in the background
  5. Click back to the original task
  6. Observe: User messages visible but faded. Claude's response completely absent. Generated files are present in workspace/folder structure confirming backend completion.

Consistency: 100% reproducible when switching during active generation.
Partial variant: If task completes fully, THEN you switch away and return, content persists ~90% of the time. The remaining ~10% still loses the render.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

COWORK

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Screenshots attached: Two screenshots demonstrating the bug state vs. working state.

  • Screenshot 1: "Adapt EquipWise content for rental website" task — user messages faded, Claude responses completely absent, loading spinner at bottom
  • Screenshot 2: "Charter news monitor" task — working correctly, response fully rendered with file card, sources, normal text opacity

Workaround: Sending any message in the affected task (even ".") forces a React re-render and sometimes recovers the completed response. This is consistent with #26921's finding. However, this wastes tokens and creates noise in the conversation history.

Workflow impact: I'm a Max plan subscriber using Cowork primarily for file creation and management workflows (CLAUDE.md updates, skill packages, website builds). File creation is inherently async — tasks take 1-5 minutes. Being forced to watch each task without switching defeats Cowork's core UX promise. This bug effectively makes Cowork single-tasking software.

Subscription: Max plan ($200/mo)

<img width="1361" height="954" alt="Image" src="https://github.com/user-attachments/assets/d1e5ab26-295d-46d7-845d-d2acc20433f1" />

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗