[BUG] Cowork tab fails to render after 1.18286.2 → 1.19367.0 auto-update — backend fully healthy (Windows 10)

cowork-tab-bug-log-excerpt.txt

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?

The Cowork tab (top nav, between Home and Code) has disappeared — only Home and Code are shown. It worked fine until the app auto-updated, and it does not come back.

Splitting this out from #75321 at the reporter's suggestion (thanks @jackhstar). That issue is a platform-detection / VM-never-starts failure (yukonSilver status=unsupported, cleanupVMBundleIfUnsupported removes the bundle). My case is different: the VM backend is fully healthy and the bundle is intact — only the UI fails to render the tab. Clean regression from 1.18286.2 → 1.19367.0. Full sanitized log attached.

Environment

Windows 10 Pro 19045 (x64)
Claude Desktop 1.19367.0.0 — MSIX, Publisher "Anthropic, PBC" (sideloaded, self-updating; not the Store)
Plan: Max
Multi-monitor setup (mixed DPI)
Clean regression — broken build went live the morning it broke

2026-07-08 07:59:13 [updater] Version changed since last launch: 1.18286.2 → 1.19367.0
Backend is fully healthy (key difference from #75321)

[VM:start] Startup complete, total time: 17253ms
[VM] API reachability: REACHABLE
[WarmLifecycle:cowork] Initialized (arm=always)
[CoworkFilePreview] Protocol handler registered
[compliance] coworkHipaaRestricted at app-ready: unrestricted
[remoteUploadsMigration] gate=claudeai_cowork_backend_marketplaces value=true
Services: vmcompute + hns Running (Automatic), CoworkVMService Running
No yukonSilver ... unsupported and no cleanupVMBundleIfUnsupported anywhere on the day it broke (that string appears only in mid-June, when the HCS services happened to be down). The VM bundle is intact and the VM boots — so this is NOT the bundle-deletion path from #75321.
Likely trigger / repro Multi-monitor. The app was backgrounded ~86 min during a browser session, then refocused, moved to another monitor and maximized. The UI re-initialized with brief hangs, and the tab did not come back:

10:58:46 [CCD] LocalSessions.setFocusedSession: sessionId=null
10:58:57 / 11:01:16 [event-loop-stall] main process blocked
[WarmLifecycle:cowork] Destroyed / Initialized (cycling)
Does not recover Full app restart, full PC reboot, and reinstall of the same 1.19367 MSIX did not restore the tab. No toggle exists to re-enable it anywhere (sidebar customize / Cowork settings / General settings). claude.com serves the same 1.19367.0.0, so reinstalling can't help.

Related: #75321 (distinct failure mode: platform detection / VM never starts). Happy to provide full logs or run any diagnostic.

What Should Happen?

The Cowork tab should render whenever the Cowork backend is available — which it demonstrably is here (VM boots, API REACHABLE, all gates true, services running). It should stay visible across window focus changes, moving the window between monitors, maximizing, and app restarts, and it should not disappear on a routine 1.18286.2 → 1.19367.0 update. Once the backend reports supported/healthy, the tab should recover on the next launch instead of staying hidden.

Error Messages/Logs

Steps to Reproduce

Windows, multi-monitor setup, on a build where the Cowork tab is present and working (for me: 1.18286.2).

Let the app auto-update to 1.19367.0 (activates on next launch).
Use the app normally, then leave the Claude window backgrounded / on a secondary monitor for a while (~1h) while working in another app (e.g. a browser).
Bring the Claude window back to the foreground, move it to another monitor, and maximize it.
The app briefly hangs / becomes unresponsive while the UI re-initializes (event-loop stalls in the log).
After it recovers, the Cowork tab is gone — only Home and Code remain.
Restarting the app, rebooting the PC, and reinstalling the same 1.19367 build do NOT bring it back, even though the VM backend is healthy (VM boots, API REACHABLE, services running).
Note: appears timing/state dependent rather than 100% deterministic; the common factor is the 1.18286.2 → 1.19367.0 update combined with a window-focus/monitor re-init. The backend never reports "unsupported" during any of this.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.18286.2

Claude Code Version

1.19367.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_