--doctor reports "unknown" backend on invalid COWORK_VM_BACKEND; daemon silently auto-detects

[RayCharlizard]

Summary

claude-desktop --doctor reports Cowork isolation: unknown ('foo') when COWORK_VM_BACKEND is set to an invalid value, but the daemon at scripts/cowork-vm-service.js:2222-2236 logs Unknown backend override "foo", falling back to auto-detect and then runs whatever auto-detection yields (typically bwrap). The diagnostic output lies about what the daemon will actually do.

Reproduction

COWORK_VM_BACKEND=docker claude-desktop --doctor
# Doctor output: "Cowork isolation: unknown ('docker')"
# Daemon actually runs: bwrap (via auto-detect fallback)

Context

Surfaces with the invalid-backend *) fallthrough added in PR #324. The [WARN] + valid-values hint the PR emits is genuinely useful — this issue only covers the cowork_backend= string that follows.

Suggested fix

In the case ${COWORK_VM_BACKEND,,} block in scripts/launcher-common.sh, the *) arm should warn about the invalid value (as PR #324 does) and then fall through to the existing auto-detect cascade below, so the displayed cowork_backend matches what the daemon will actually select. Structurally this means lifting the override case into an early return for the three valid values and letting invalid values drop into the existing elif command -v bwrap / elif [[ -e /dev/kvm ]] ladder.

Keeping this scoped to a separate PR rather than expanding #324 to respect the original author's submission.

---

Written by Claude Opus 4.7 (1M context) via Claude Code

[github-actions]

The --doctor output is lying to you here. When COWORK_VM_BACKEND is set to an invalid value, the *) fallthrough in launcher-common.sh assigns that invalid string as cowork_backend and displays it. But the daemon never uses that value — it runs its own auto-detection at startup and picks a valid backend silently.

So --doctor shows unknown (or whatever garbage string you passed), while the daemon is actually running qemu or virt. The fix is to let invalid values fall through to the same auto-detect ladder the daemon uses, so the diagnostic reflects what actually runs.

You can verify the mismatch yourself: set COWORK_VM_BACKEND=garbage, run --doctor, then check the running daemon. Related: #288 hit a similar gap between what the config said and what the daemon did at runtime.

The fix scope is narrow — just launcher-common.sh's backend resolution logic.

---

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]

Quick correction for the record, since the triage bot above got two details wrong:

• Backend names. The valid COWORK_VM_BACKEND values are kvm, bwrap, and host — not qemu or virt. Reference: cowork-vm-service.js:2226-2232.
• Cowork fails to start the VM due to missing qcow2 files #288 isn't a precedent for this. That issue was about KVM VM startup failing due to a missing rootfs.qcow2, not a config-display vs daemon-behavior mismatch. Different failure mode.

The rest of the bot's restatement of the problem is accurate. Leaving its comment in place for the triage audit trail.

---

Written by Claude Opus 4.7 (1M context) via Claude Code

[aaddrick]

Triage bot needs some love. I'm digging into a redesign now.