[BUG] Cowork gates on /etc/os-release ID=pop rather than ID_LIKE, blocking fully-capable Pop!_OS hosts
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?
Related to: #74605 (same general area — Cowork Linux capability gating — but a distinct root cause)
Summary
Cowork refuses to enable on Pop!_OS 22.04 with the message "Cowork requires QEMU,"
even when QEMU, OVMF, virtiofsd, KVM access, and vhost_vsock are all correctly
installed and verified working. Root cause appears to be that the capability check
gates on the literal ID field in /etc/os-release rather than ID_LIKE.
Environment
- OS: Pop!_OS 22.04 LTS (Jammy-based)
- /etc/os-release:
ID=pop
ID_LIKE="ubuntu debian"
VERSION_CODENAME=jammy
UBUNTU_CODENAME=jammy
- Claude Desktop: official .deb from Anthropic's apt repo
Steps to reproduce
- Install Claude Desktop on Pop!_OS 22.04 via official apt repo
- Install qemu-system-x86, ovmf, and virtiofsd (via Noble .deb backport,
since virtiofsd isn't packaged for Jammy)
- Confirm /dev/kvm accessible, user in kvm group
- Confirm vhost_vsock kernel module loaded
- Open Cowork tab
Expected
Cowork enables, since all underlying virtualization dependencies are present
and functional.
Actual
UI shows: "Cowork requires QEMU. Install it with 'sudo apt install
qemu-system-x86 ovmf virtiofsd', then restart Claude." — despite all three
already being installed.
Log (~/.config/Claude/logs/cowork_vm_node.log) shows the capability check
(feature key yukonSilver) reporting unsupported instantly on every helper
spawn, with no per-dependency detail:
[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported),
checking for stale bundle...
This fires at the same instant on every restart regardless of what local
dependencies are fixed, suggesting a coarse gate rather than a real probe.
Root cause (confirmed via isolation test)
Backed up /etc/os-release, then temporarily changed:
ID=pop → ID=ubuntu
(ID_LIKE left unchanged as "ubuntu debian")
Fully quit and relaunched Claude Desktop. Cowork became available immediately.
Reverted /etc/os-release back to ID=pop afterward.
This confirms the capability check keys off the literal ID field rather than ID_LIKE, incorrectly excluding Ubuntu-derivative distros (Pop!_OS, and likely
others like Linux Mint, Zorin OS, elementary OS) that report a different ID
but share full binary/library compatibility with their base.
Suggested fix
Have the capability check also accept ID_LIKE containing "ubuntu" or "debian"
(with an appropriate version/codename check via VERSION_CODENAME or
UBUNTU_CODENAME, both of which are present and correct on Pop!_OS), rather
than gating solely on ID.
Additional dependency note (may help other Jammy-based users)
virtiofsd is not packaged for Ubuntu Jammy/22.04 at all — it only appears
starting with Noble (24.04). Users on Jammy-based distros following the
"sudo apt install ... virtiofsd" instruction will hit "no installation
candidate" and need to manually install the Noble .deb.
What Should Happen?
Expected
Cowork enables, since all underlying virtualization dependencies are present
and functional.
Error Messages/Logs
Steps to Reproduce
Steps to reproduce
- Install Claude Desktop on Pop!_OS 22.04 via official apt repo
- Install qemu-system-x86, ovmf, and virtiofsd (via Noble .deb backport,
since virtiofsd isn't packaged for Jammy)
- Confirm /dev/kvm accessible, user in kvm group
- Confirm vhost_vsock kernel module loaded
- Open Cowork tab
Claude Model
Sonnet (default)
Is this a regression?
No, this never worked
Last Working Version
_No response_
Claude Code Version
2.1.59 (Claude Code)
Platform
Anthropic API
Operating System
Other Linux
Terminal/Shell
Other
Additional Information
_No response_