# v1.3.31+claude1.2773.0: cowork-vm-service daemon terminates mid-session and does not recover; persists across reboot

[RayCharlizard]

Environment

• Package: claude-desktop-appimage (AUR)
• Version: 1.3.31+claude1.2773.0-1
• Install date: 2026-04-15 22:49:47 CDT
• Distro: CachyOS Linux (rolling), kernel 7.0.0-1-cachyos
• Desktop: KDE Plasma on Wayland (XWayland for Claude Desktop, --ozone-platform=x11)
• Shell: fish 4.1.2
• Cowork backend: host-direct (via override)
• Previous release on same system: worked correctly

Summary

On host-direct backend, cowork-vm-service starts and functions normally on a fresh launch of this version. After roughly 40 minutes of active use (two completed Cowork sessions), the daemon terminates without logging a cause — surfaced only by a [Keepalive] Ping failed on the Node-side vm-client. From that point forward the daemon is never re-spawned: not by the running app, not after a full quit + relaunch, and not after an OS reboot. Auto-reinstall triggers once on the next launch (preserving sessiondata.img and rootfs.img.zst) and fails identically on retry.

End state: no cowork-vm-service process, no Unix socket at /run/user/$UID/cowork-vm-service.sock, no daemon stderr captured anywhere, and vm-client retrying connect() in an ENOENT loop.

Reproduction

1. Install v1.3.31+claude1.2773.0 on host-direct backend.

2. Launch Claude Desktop.

3. Open Cowork sessions and use them normally — this works.

4. After some period of use (in my case ~40 minutes with two sessions), a keepalive ping failure is logged and the daemon terminates.

5. Every subsequent attempt to open a Cowork session (in the same running app, after a full quit+relaunch, and after an OS reboot) fails with:

   Failed to start Claude's workspace
   VM service not running. The service failed to start.

Timeline from logs (single continuous session)

All times CDT, same day as install.

Time	Event
22:49:47	Package installed
22:50:23–22:50:25	VM startup succeeds: download_and_sdk_prepare, load_swift_api, smol-bin.x64.vhdx copy, Keepalive: Starting, Startup complete, total time: 1896ms
22:51:01	First Cowork session amazing-upbeat-mendel spawned successfully
22:58:17	Second Cowork session tender-dazzling-mccarthy spawned successfully
23:09:48	First session killed cleanly (SIGTERM, code=0, duration=1127362ms)
23:32:11	[Keepalive] Ping failed: Keep-alive ping timed out
23:32:18	[Keepalive] Ping failed: Keep-alive ping timed out
(OS reboot)
23:45:27	App starts. appVersion: '1.2773.0'
23:45:35	[VM:start] Beginning startup → download_and_sdk_prepare ✓ → load_swift_api ✓ → Copying smol-bin.x64.vhdx ✓
23:45:40	[error] [VM:start] VM boot failed: VM service not running. The service failed to start.
23:45:40	[VM:start] Auto-reinstalling workspace after startup failure — reinstall files deleted, sessiondata.img and rootfs.img.zst preserved
23:45:44	Retry: identical failure
23:45:44	[VM:start] Skipping auto-reinstall (already attempted once)
23:51:12+	Subsequent launches: identical failure every time

Between the successful 22:58:17 session spawn and the 23:32:11 keepalive failure there are no daemon-side log entries at all — the daemon dies silently and is only detected when the Node-side client's periodic ping stops getting a response.

Diagnostic state while the failure is active

claude-desktop --doctor

Cowork Mode
----------------
[PASS] bubblewrap: found
[PASS] KVM: accessible
[PASS] vsock: module loaded
[PASS] QEMU: found
[PASS] socat: found
[PASS] virtiofsd: found
      VM image: not downloaded yet
      Cowork isolation: host-direct (no isolation, via override)

(One unrelated [FAIL] for chrome-sandbox perms inside the AppImage FUSE mount; suggested fix — chmod 4755 inside a read-only FUSE mount — cannot be applied. Electron's --no-sandbox workaround is in effect and launches fine. Minor separate issue.)

No daemon process, no bwrap, no claude CLI

App running, Cowork session failed, then:

$ ps auxf | grep -iE 'cowork|claude' | grep -v grep

Returns only the Electron main process, zygotes, and NetworkService / AudioService utility children. No cowork-vm-service Node process. No bwrap. No /usr/local/bin/claude CLI.

No socket, no orphans

$ lsof -U 2>/dev/null | grep -iE 'cowork|claude'
(empty)
$ ls /run/user/$UID/cowork-vm-service.sock
No such file or directory
$ ls /tmp/cowork-* 2>/dev/null
(none)

The daemon file ships correctly

$ find /tmp -path '*claude*cowork-vm-service*'
/tmp/.mount_clauder22nbF/usr/lib/node_modules/electron/dist/resources/app.asar.unpacked/cowork-vm-service.js

/usr/bin/claude-desktop is a symlink to the AppImage

$ file /usr/bin/claude-desktop
/usr/bin/claude-desktop: symbolic link to /opt/claude-desktop/claude-desktop.AppImage

No separate wrapper/launcher sits between the shell and the AppImage bootstrap, so the daemon spawn has to happen from inside app.asar.

Launcher log: endless client-side retry

~/.cache/claude-desktop-debian/launcher.log fills with:

[vm-client] Event subscription error: connect ENOENT /run/user/1000/cowork-vm-service.sock
[vm-client] Event subscription error: connect ENOENT /run/user/1000/cowork-vm-service.sock
[vm-client] Event subscription error: connect ENOENT /run/user/1000/cowork-vm-service.sock
...

ENOENT rather than ECONNREFUSED confirms the socket file was never created on this launch — no daemon came up, nothing crashed leaving a stale socket, nothing tried and failed. The spawn call simply isn't being reached on recovery.

Observations

• The daemon does function correctly on fresh launches of this version, so the asar-level integration is not fundamentally broken.
• What regressed is the recovery path: after the daemon dies mid-session, no code path re-spawns it, and this persists across full app restart and OS reboot.
• Auto-reinstall deletes "reinstall files" but preserves sessiondata.img and rootfs.img.zst. Retrying with those preserved files produces the identical failure. Whether those files are implicated in the stuck state is unconfirmed — I haven't tested manual deletion.
• The initial daemon termination at 23:32 has no captured cause. Nothing in cowork_vm_node.log between the successful second session spawn at 22:58 and the first keepalive ping failure at 23:32.

Workaround

Downgrade to the previous release. Manual deletion of sessiondata.img and rootfs.img.zst in ~/.config/Claude/vm_bundles/claudevm.bundle/ is untested as a recovery step — happy to test on request before filing if helpful.

Additional notes

Separately, sessions-bridge reports a 409 registration conflict because a Cowork agent is already registered on another device under the same account. This is expected given the current single-device lock and not part of this report.

[github-actions]

I've tracked this down to Patch 6 in build.sh. The _svcLaunched guard is a one-shot boolean. It's set to true on first daemon launch and never cleared. When the daemon crashes mid-session, every retry in zut() sees the guard already set and skips the spawn. You get the infinite ENOENT loop with no recovery path.

There's a second compounding issue. If the daemon exits without cleaning up its socket, a full app restart resets the guard. But the new daemon tries to bind on a stale socket path and hits EADDRINUSE. The full-restart recovery fails too.

On Linux, the upstream heartbeat respawn path (wTn()) calls the Swift VM native addon and fails immediately with "Swift VM addon not available". Our injected spawn in zut() is the only spawn mechanism on Linux. Both issues need to be patched there.

The fix is in Patch 6: replace the boolean guard with a timestamp-based rate limiter, and unlink the stale socket before each spawn attempt.

// Replace: !FUNC._svcLaunched && (FUNC._svcLaunched=true, ...)
// With:
(!FUNC._lastSpawn || Date.now()-FUNC._lastSpawn > 10000) &&
(FUNC._lastSpawn=Date.now(), (()=>{
  try {
    try { require("fs").unlinkSync(
      (process.env.XDG_RUNTIME_DIR||"/tmp")+"/cowork-vm-service.sock"
    )} catch(_) {}
    // ... spawn daemon ...
  } catch(_e) { console.error("[cowork-autolaunch]",_e) }
})())

The 10-second cooldown allows respawn after crash and prevents rapid restart loops.

---

This is an automated triage comment. A maintainer will review this issue and may provide further guidance.

Written by Claude Sonnet via Claude Code

[RayCharlizard]

One observation from rolling back that may indicate a separate issue layered on top of the _svcLaunched guard:

Downgrading to v1.3.30+claude1.2278.0 on its own wasn't sufficient — the older AppImage also failed to start the daemon against the leftover state from v1.3.31. I had to also wipe:

• ~/.config/Claude/vm_bundles/claudevm.bundle/
• ~/.config/Claude/claude-code-vm/

After that, 1.3.30 launched cleanly and Cowork works normally.

The _svcLaunched guard is process-local, so after OS reboot a fresh process should have a clean guard and spawn. But it didn't — and neither did a full version downgrade. The preserved sessiondata.img / rootfs.img.zst retained by auto-reinstall appear to put the daemon in a state where it can't start, which is consistent with the client seeing ENOENT on the socket path (daemon never got far enough to create it) rather than ECONNREFUSED.

The Patch 6 fix (rate-limited spawn + stale socket unlink) should resolve the mid-session recovery path. For the persistent-state case, it may be worth either wiping those preserved image files in the auto-reinstall path, or at minimum surfacing the daemon's init failure so we get a real error rather than a silent ENOENT loop on the client.

Happy to test a patched build.

[Sim4n6]

same issue

[lobsteinda]

Same problem