[BUG] Cowork (Windows): VM cold-start timeout triggers "Auto-reinstalling workspace" and quits/relaunches Claude Desktop, dropping the remote-device bridge

Status Open
Maintainer reply None cached
Activity 0 comments · opened Oct 12, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report
  • [x] I am using the latest version of Claude Desktop

What's Wrong?

Product: Claude Desktop (Windows, MSIX), Cowork / remote-device bridge. Not the CLI.

When a scheduled cloud routine runs a shell command on the PC through the remote-device bridge, Claude Desktop cold-starts the sandbox VM. If that start passes the 30 s startup timeout, the app logs "Auto-reinstalling workspace" in the same second, then quits and relaunches the whole app. The quit is a plain beforeQuit, not beforeQuitForUpdate, and the app version is the same before and after. The relaunch:

  • drops the remote-device bridge for about 1.5 minutes, so the routine sees "not connected" and then 60 s timeouts, with no reason given;
  • deletes the VM kernel files, so the next start has to rebuild them and takes even longer.

Seen on two separate nights (same pattern both times). On a third night the VM start timed out the same way but the app did not quit, so the quit doesn't follow every timeout.

Context: every failing start was in the early morning while the laptop was very likely in Modern Standby (S0 low-power idle, network still connected). Daytime starts finish the SDK install step in 0.3–17 s. Standby probably makes the start slow. Still, a slow VM start shouldn't tear down the whole app and the bridge with it.

What Should Happen?

  • A VM startup timeout should retry the VM start, or report "workspace starting / unavailable" to the caller. It shouldn't quit and relaunch Claude Desktop.
  • Auto-repair shouldn't delete the VM kernel files on a timeout alone.
  • Bridge callers should get an error that says the VM is starting or the app is restarting, not a bare "not connected" or a 60 s timeout.
  • Optionally, a longer startup timeout or one that adapts when the host has just left low-power idle.

Error Messages/Logs

Sequence from main.log / cowork_vm_node.log, the same on both nights (relative times):

t+0s     device bridge serves the routine's call
t+35s    VM cold start begins
t+80s    sdk_install step starts
t+110s   Startup failed: request timed out after 30s
t+110s   Auto-reinstalling workspace -> app beforeQuit -> bridge closes
t+120s   Claude Desktop relaunches
t+210s   bridge authenticated again

Steps to Reproduce

  1. Windows laptop that supports only S0 Modern Standby (no S3), plugged in, screen set to turn off after a few minutes, network connected in standby.
  2. Set up a scheduled cloud routine bound to this PC that runs a device_bash command early in the run.
  3. Let the PC go into Modern Standby for several hours before the scheduled time.
  4. When the routine fires, the VM cold start times out after 30 s, the app logs "Auto-reinstalling workspace", quits and relaunches, and the bridge drops for about 1.5 min.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Claude Desktop Version

2.31226.1 (MSIX)

Operating System

Windows 11 Pro (build 26300)

Related

#91645 and #93137 (VM service stops and never restarts: a different failure), #93385 (auto-repair deletes data), #77385 (bridge disconnects).

View original on GitHub ↗