[BUG] [BUG] Cowork tab silently removed by server-side `yukonSilver unsupported` flag after working for months — active project inaccessible

Resolved 💬 3 comments Opened Apr 19, 2026 by AnatriusTorrens Closed May 26, 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?

  • OS: Windows 11 Pro x64, virtualization features enabled
  • App version at time of failure: 1.3109.0 (latest auto-update)
  • VM bundle version: 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d
  • Cowork had been working continuously since March 2026

Cowork tab disappeared from Claude Desktop on April 19, 2026. The app now deletes the VM bundle on every launch because the server classifies my yukonSilver VM configuration as unsupported, despite the exact same hardware running Cowork successfully for over a month.

Timeline from cowork_vm_node.log:

  • March–April 18: Cowork working normally. Multiple successful sessions on my project. Last successful session ended 2026-04-18 23:36:37.
  • April 19, 13:40:15 (first launch of the day): yukonSilver not supported → VM bundle auto-deleted.
  • Every subsequent launch: same pattern. Cowork tab gone.

What I already tried (none worked):

  • Full uninstall + cleanup of %APPDATA%\Claude and %LOCALAPPDATA%\Claude + reinstall
  • Running installer as Administrator
  • Reboot
  • Waiting between launches

All pointless by design — the server flag is reapplied on every startup.

Business impact

I have an active project that lived inside Cowork with its own configured workspace, skills, and session history. Cowork is advertised as production-capable for knowledge workers. Silently disabling it for paying users mid-project, with no warning, no rollback, and no client-side fix, is unacceptable — even for a research preview.

What Should Happen?

  1. Remove the unsupported flag for my configuration on the server side.
  2. Publish a postmortem for users whose VM gets reclassified — what criteria, what recovery path.
  3. Stop auto-deleting VM bundles when the server returns unsupported. Ask the user first.
  4. Surface this state in the UI instead of hiding the tab silently.

Happy to provide full logs, app version, account email via support channel.

Error Messages/Logs

Log fragment (last success on April 18 → failures on April 19):

2026-04-18 23:36:09 [info] [Spawn:create] id=08c60a68-fab5-4610-906a-b4af92f3a858 name=funny-wizardly-dijkstra cmd=/usr/local/bin/claude ...
2026-04-18 23:36:09 [info] [Spawn:vm] id=08c60a68-fab5-4610-906a-b4af92f3a858 OAuth token approved with MITM proxy
2026-04-18 23:36:09 [info] [Process:08c60a68-fab5-4610-906a-b4af92f3a858] Spawn confirmed, flushing 2 buffered stdin chunks
2026-04-18 23:36:09 [info] [Spawn:vm] id=08c60a68-fab5-4610-906a-b4af92f3a858 Spawn succeeded in 77ms
2026-04-18 23:36:37 [info] [CoworkVMProcess:08c60a68-fab5-4610-906a-b4af92f3a858] kill called with signal: SIGTERM
2026-04-18 23:36:37 [info] [Process:08c60a68-fab5-4610-906a-b4af92f3a858] Exited, code=0, signal=null, duration=28378ms, oom=false
2026-04-18 23:36:37 [info] [Process:08c60a68-fab5-4610-906a-b4af92f3a858] Cleaned up, remaining active=0

2026-04-19 13:40:15 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-04-19 13:40:15 [info] [deleteVMBundle] Deleting reinstall files from C:\Users\...\AppData\Roaming\Claude\vm_bundles\claudevm.bundle
2026-04-19 13:40:15 [info] [deleteVMBundle] Reinstall files deleted (sessiondata.img and rootfs.img.zst preserved)
2026-04-19 13:40:16 [info] [VM] Loading vmClient (TypeScript) module...
2026-04-19 13:40:16 [info] [VM] Module loaded successfully
2026-04-19 13:41:11 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-04-19 13:41:11 [info] [deleteVMBundle] Reinstall files deleted (sessiondata.img and rootfs.img.zst preserved)
2026-04-19 14:03:20 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-04-19 14:03:20 [info] [deleteVMBundle] Reinstall files deleted (sessiondata.img and rootfs.img.zst preserved)
2026-04-19 16:23:17 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-04-19 16:23:17 [info] [deleteVMBundle] Reinstall files deleted (sessiondata.img and rootfs.img.zst preserved)
2026-04-19 16:50:13 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-04-19 16:50:13 [info] [deleteVMBundle] Reinstall files deleted (sessiondata.img and rootfs.img.zst preserved)
2026-04-19 16:53:37 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-04-19 16:53:38 [info] [deleteVMBundle] Reinstall files deleted (sessiondata.img and rootfs.img.zst preserved)

Steps to Reproduce

Root cause

Server-side misclassification, identical to #25136. The yukonSilver status is returned by Anthropic's backend, not determined locally. No client action can fix it — the app cheerfully deletes its own VM bundle based on whatever the server says.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.111

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_

View original on GitHub ↗

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