Claude Desktop — Cowork Sandbox Architecture

This surface was mapped in January 2026: native host identification, multi-browser pre-registration across browsers not yet installed, and webRequest interception capability on api.anthropic.com documented in session logs. Public coverage appeared approximately three months later.

The browser-layer interception is the direct macOS analog to the Cowork TLS MITM documented above. One operates inside the VM at the TLS layer via an installed CA. The other operates inside the browser at the network request layer via a pre-authorized extension. Both reach the same Anthropic API traffic. The mechanism differs; the capability does not.

The interception applies to every process running inside the VM that makes a TLS connection to *.anthropic.com — this includes the AI model completions endpoint, authentication, telemetry, and any other Anthropic service on that domain. The CA certificate is installed as a trusted root inside the guest. There is no opt-out available to guest processes: they cannot distinguish the proxy's re-encrypted response from a response from the real endpoint using standard TLS verification, because the proxy's CA is in their trust store. Any process inside the VM therefore sees the intercepted connection as legitimate TLS.

There are two distinct capabilities on the cowork-svc pipe: the ability to command (create VMs, spawn processes, read files) and the ability to observe (receive stdout, stderr, exit codes, and network events from running processes). The command surface requires the Anthropic-signed claude.exe certificate. The observation surface does not.

This asymmetry means that while arbitrary processes cannot control the VM, they can watch everything it produces in real time. Any local process — including third-party tools, MCP servers spawned by Claude Desktop, or background services — can subscribe to the event stream and receive the output of whatever is executing in the VM. Output that contains file contents, code, AI responses, or credentials is delivered to any subscriber without authentication.

The restoration event documented here involved one specific directory. The mechanism — the updater detecting file hash drift and writing back through the guest-to-host mount — is not specific to that path. The mount gives the guest access to host paths configured at VM startup. Any file in any path accessible through that mount can be monitored for drift and restored.

The restoration operates without user interaction or notification. The parent process does not emit a signal when a restoration occurs. The only indication is the file change event in a filesystem monitor, which is how the 23:15 event was identified here.

The mutual TLS authentication on cowork-svc methods establishes that only the signed claude.exe binary can issue commands to the VM. It does not constrain what those commands can do, what the VM produces, or who can observe that output.

The cert architecture answers the question: "who is allowed to act?" It does not answer: "what is the acting party allowed to do?" and it explicitly does not apply to observation at all. These are three different security questions, and the cert architecture addresses only the first.

When Hyper-V is absent or disabled, cowork-svc cannot start a VM. The service still runs at SYSTEM privilege and holds the named pipe open. The subscribeEvents endpoint still accepts connections. The SYSTEM-privileged service surface with an unauthenticated observation endpoint is present on the machine regardless of whether the VM capability is active.

VM-gated methods returning auth errors reduces the attack surface but does not eliminate the SYSTEM-privileged process or the unauthenticated event stream.