Claude desktop teardown: MCP servers run outside the VM

A teardown of the Claude desktop app, build 1.40609.1, found that a local MCP server runs as an ordinary macOS process outside the Linux VM that isolates agent code in Cowork. The analysis of the 855.2 MB bundle was published by Telkins.

At a glance

• Cowork boots its Linux guest through Apple's Virtualization.framework, and the Ubuntu 22.04.5 root disk downloads at runtime as a 1.23 GB compressed image that expands to exactly 10 GiB.
• Sandbox settings allowlist npm, PyPI, GitHub, Ubuntu archives, crates.io and Anthropic domains, while requests to Anthropic and Claude hosts pass through a MITM proxy bound to a Unix socket inside the guest.
• The split matters because tools dispatched to the guest daemon run under a separate kernel, while host-side components such as MCP servers keep the file access their macOS permissions allow.

The sandbox reads as a defence-in-depth arrangement rather than a single boundary: the VM covers code the agent generates, while the coordination layer that dispatches tool calls sits on the Mac. For anyone wiring local MCP servers into the app, that likely moves the security question away from the guest image and back onto ordinary macOS permissions, since a host process can reach files that were never shared into the VM at all.

A Python MCP probe reported Darwin and process ID 18717 on the host

To locate where a local MCP server executes, the author added a small Python server to Claude's configuration and asked a local Cowork session to call its single tool, which reported the operating system and process ID before reading a test file. The tool returned Darwin and PID 18717.

The macOS process table showed that same process running under Claude, with a parent chain of Claude at 18616, a helper binary named disclaimer at 18716, and the Python probe at 18717. The response inside Cowork carried a random marker saved in /private/tmp, a path never shared into the guest.

Coordination of tool calls also happens on the Mac. The teardown reports that this work originally ran inside the VM, that a failed VM startup could leave Claude unable to respond, and that moving it to the host lets Claude help diagnose such a failure.

About 60% of the 855.2 MB bundle is Electron and Chromium

Roughly 60% of the bundle is the Electron framework and its Chromium resources, with native interop held in .node binaries dynamically linked against Apple frameworks. The bundled web frontend sits in ion-dist, alongside smol-bin disk images of 24 MB each in separate arm64 and x64 copies.

Those images are not the bootable guest but a utility volume mounted inside it. Their srt-settings.json allowlists registry.npmjs.org, yarnpkg.com, pypi.org, files.pythonhosted.org, github.com, Ubuntu archive and security hosts, api.anthropic.com and crates.io, permits local binding and all Unix sockets, and denies reads of /run/systemd/resolve and /run/dbus.

Traffic to Anthropic and Claude domains, including frame.claudeusercontent.com, routes through a MITM proxy on /var/run/mitm-proxy.sock. Anthropic added that proxy after an exfiltration bug in which a malicious file pushed workspace files to an attacker's account through its own API, and it requires the VM's provisioned session token.

The runtime-downloaded guest runs Ubuntu 22.04.5 with a Go daemon as root

The manifest for the arm64 base image revision 2a762adf, published August 13, 2026, lists four artifacts: rootfs.img, vmlinuz, initrd, and a smaller initrd-micro for the fast-boot path. The root disk is 1.23 GB compressed and expands to a 10 GiB disk with a 99 MiB EFI partition and an ext4 root filesystem.

Inside are Ubuntu 22.04.5 LTS with kernel package 6.8.0-136-generic, Node.js 22.23.2, Python 3.10.12, UV, and /usr/local/bin/sdk-daemon, a stripped Go binary built with Go 1.25.12. Its coworkd.service unit describes a vsock RPC bridge for process management and runs as root inside the guest.

A Swift class named CoworkVMRPCClient exchanges JSON over vsock with that daemon, and guest network traffic leaves a virtual Ethernet interface over the same transport, with host-side Swift metadata referencing VZGvisorNetworking. Document tooling in the image includes pdfplumber, camelot, pytesseract, unoserver, markitdown and magika.

Which type names remain unresolved

Across the two native addons the teardown counted 273 Swift field descriptors and recovered names for 175 of them, covering 171 distinct types, with the remaining descriptors and some field types left unresolved. The installed Swift addons no longer include debug maps or DWARF sections in their arm64 slices, though 28 source-path strings survive in swift_addon.node, and an earlier build's debug map listed 50 filenames in ClaudeSwift and 7 in ComputerUseSwift.