Error Failed to start workspace & built in reinstall workspace unsucesful. Easy fix included

[zabka]

Hello,
First, huge thanks for creating and maintaining this repackage, game changer.

Got a bit addicted and took 2 weeks break. Come back, perform updates and Claude-desktop failed to launch the VM (with the infamous error message).
The built in feature to rebuild the workspace was not helping.

I did not consider that re-downloading the VM would help anyway as it was already there like few weeks ago

The --doctor pointed out some packages were not properly located (PATH issue) but most importantly the VM was reported not found.

I let Claude make you a quick summary and the fix, which is simply spawning cowor-vm-service.js manually before claude-desktop.

---

Root cause: cowork-vm-service.js is never auto-spawned on Linux, so /run/user/1000/cowork-vm-service.sock never exists.

Missing dependencies + Ubuntu PATH quirk

sudo apt install qemu-system-x86 socat virtiofsd
sudo ln -s /usr/libexec/virtiofsd /usr/local/bin/virtiofsd

If you clicked "Reinstall workspace", remove the blocking flag it leaves

rm ~/.config/Claude/vm_bundles/claudevm.bundle/.auto_reinstall_attempted

Auto-start the VM daemon with your session

cat > ~/.config/systemd/user/cowork-vm-service.service << 'EOF'
[Unit]
Description=Claude Desktop Cowork VM Service
After=graphical-session.target
[Service]
ExecStart=/home/YOUR_USER/.nvm/versions/node/v20.20.2/bin/node
/usr/lib/claude-desktop/node_modules/electron/dist/resources/app.asar.unpacked/cowork-vm-service.js
Restart=on-failure
RestartSec=3
[Install]
WantedBy=default.target
EOF
systemctl --user enable --now cowork-vm-service

Our 2 cents

[github-actions]

Now I have enough context to write the comment.

Two real bugs here. The virtiofsd one is a PATH gap on Ubuntu. The binary ships at /usr/libexec/virtiofsd, which isn't in $PATH by default. doctor.sh detects it as a dependency but doesn't handle the nonstandard location. The fix is either a symlink into /usr/local/bin at install time, or updating the cowork launch logic to check /usr/libexec directly.

The .auto_reinstall_attempted flag is the other issue. When "Reinstall workspace" fails, the upstream app leaves the flag set and nothing clears it. That blocks every subsequent recovery attempt until you remove it manually. The Patch 6b work from #408 extended the auto-reinstall delete list to wipe sessiondata.img and rootfs.img.zst, but this flag wasn't included. It needs to be added to the delete list, or doctor.sh needs a check that clears stale flags on startup.

Your systemd workaround is valid for now. Both root causes are fixable in the packaging scripts.

---

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

Written by Claude Sonnet via Claude Code

[aaddrick]

Hey @zabka!

What's version are you running?

We ditched the VM's for now and went with bwrap as standard. Updating to latest might resolve your problems.

[zabka]

Hi Aaddrick

[PASS] Installed version: 1.2773.0-1.3.31

[aaddrick]

Thanks — that helps.

Your version predates a handful of cowork/bwrap fixes that landed over the last few days. The ones most likely to hit your symptoms:

• fix: launcher-common.sh self-match and stale socket cleanup (#407) #425 — stale socket cleanup in launcher-common. Coming back after a 2-week gap is exactly the kind of thing this was chasing.
• fix: diagnose AppArmor userns block on bwrap probe (#351) #434 — AppArmor userns block diagnosis on bwrap probe. Ubuntu's default AppArmor profile can silently block bwrap from starting, which would look identical to "daemon never came up."
• fix: home --dir before SDK --ro-bind in bwrap sandbox #426 — bwrap sandbox arg ordering fix.

Latest is v2.0.0+claude1.3109.0, published today. sudo apt update && sudo apt upgrade should pick it up.

One terminology bit to unstick: "bwrap instead of VMs" means the sandbox inside cowork-vm-service is bwrap now, not QEMU/KVM. The daemon (cowork-vm-service.js) still runs — so the qemu/socat/virtiofsd installs weren't actually needed, and the systemd unit shouldn't be needed either once the daemon auto-launch path works.

Two things from your writeup we haven't actually fixed yet, though, so hang onto those workarounds if they bite again:

1. .auto_reinstall_attempted stale flag — the reinstall delete-list extension (# v1.3.31+claude1.2773.0: cowork-vm-service daemon terminates mid-session and does not recover; persists across reboot #408) covers the VM image files but not this flag. Opening a tracking issue.
2. virtiofsd at /usr/libexec/ — doctor.sh doesn't check that path. Also tracking.

Let us know if upgrading clears it.

---

Written by Claude Opus 4.7 via Claude Code

---

Generated by Claude Code

[zabka]

Hi, here the update after system reboot:
[PASS] Installed version: 1.3109.0-2.0.0
[FAIL] bubblewrap: sandbox probe failed (rc=1)
stderr: bwrap: setting up uid map: Permission denied

Claude-desktop works like a charm, rw in claude-code is confirmed.

(and I removed my dirty fix otherwise of course we get an orphan)

Thank you

[RayCharlizard]

Hi @zabka — the doctor.sh false-negative you hit on Ubuntu (your manual sudo ln -s /usr/libexec/virtiofsd /usr/local/bin/virtiofsd workaround) now has a fix in flight: #453.

After that lands, --doctor will probe the off-PATH install locations directly and report [PASS] virtiofsd: found at /usr/libexec/virtiofsd (not on PATH) on stock Ubuntu instead of the misleading "not found." The symlink isn't strictly needed for the bwrap default (virtiofsd isn't used there), so the PASS is honest. If you ever opt into COWORK_VM_BACKEND=kvm, doctor will escalate to [WARN] and suggest the symlink since KvmBackend spawns by PATH name and would otherwise silently fall back to virtio-9p.

The other thread from your report — the stale .auto_reinstall_attempted flag — is tracked separately and is still on the to-do list.

---

Written by Claude Sonnet 4.7 via Claude Code