[Bug] Cowork sessions fail to start: sandbox dependency check fails inside VM

Resolved 💬 4 comments Opened Feb 17, 2026 by aieutics Closed Feb 17, 2026

Environment

  • Claude desktop app v1.1.3189 (latest as of 2026-02-17)
  • macOS Darwin 25.2.0 (Sequoia)
  • Claude SDK v2.1.41 (auto-installed inside VM on boot)
  • VM image: claudevm.bundle/rootfs.img (Ubuntu 22.04)

Error message

CLI output was not valid JSON. This may indicate an error during startup.
Output: Error: Sandbox dependencies are not available on this system.
Required: ripgrep (rg), bubblewrap (bwrap), and socat.

What happens

When starting a new Cowork session, the Claude desktop app boots a Linux VM (Ubuntu 22.04 via Apple Virtualization framework), installs the Claude SDK (v2.1.41) inside it, and then launches /usr/local/bin/claude as a subprocess. The CLI immediately checks for sandbox dependencies — ripgrep (rg), bubblewrap (bwrap), and socat — which are required to run tools in a sandboxed environment. These binaries are not present in the VM's root filesystem image (rootfs.img). The CLI exits within ~400ms. The desktop app receives the error output instead of the expected JSON stream, surfaces the "CLI output was not valid JSON" wrapper message, and the session never starts.

From cowork_vm_node.log:

[Spawn:vm] Spawn succeeded in 157ms
[CoworkVMProcess] kill called with signal: SIGTERM
[Process] Exited, code=0, signal=null, duration=422ms, oom=false

The VM itself boots correctly — network connects, virtiofs mounts succeed, the SDK installs, OAuth tokens are approved. The failure is strictly at the CLI startup stage after all infrastructure is ready.

What should happen

The sandbox dependency check should pass inside the Cowork VM. This requires one of:

  1. The VM root filesystem image (rootfs.img) should ship with rg, bwrap, and socat pre-installed. Since the CLI enforces these as mandatory sandbox dependencies, and the VM is a controlled environment built by Anthropic, these packages should be baked into the image at build time.
  1. Alternatively, the sandbox check should be skipped inside the Cowork VM. The VM already provides isolation — it runs in a sandboxed virtualised environment with controlled filesystem mounts, a MITM proxy for network, and per-session user accounts. Running bubblewrap sandboxing inside an already-sandboxed VM is defence-in-depth, but if the dependencies can't be guaranteed, the CLI should detect that it's running inside a Cowork VM and either disable the sandbox or fall back gracefully.
  1. The ~/.claude/settings.json sandbox override should be respected. The user-side config already contains "sandbox": { "enabled": false }, but this file lives on the host Mac. Inside the VM, the settings are mounted via virtiofs at a different path and may not be read before the dependency check runs. The CLI should load user settings before performing the sandbox gate check.

Likely root cause

A version mismatch between the Claude SDK (v2.1.41, downloaded dynamically on each VM boot) and the VM root filesystem image (static, shipped with the desktop app). The SDK was updated to enforce sandbox dependencies that the VM image predates. The previous SDK version either didn't have this check or had these tools bundled differently.

Workaround attempted

  • Setting "sandbox": {"enabled": false} in ~/.claude/settings.json on the host — no effect (setting not read inside VM before the check).
  • No user-accessible way to install packages inside the VM or modify rootfs.img.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗