linux-container-environment-report.md

Linux Container Environment Report

Generated: January 13, 2026 Session ID: brave-loving-maxwell

---

Executive Summary

This report details the Linux container environment powering the Claude AI assistant's "Cowork mode." The environment is a lightweight, highly sandboxed Ubuntu 22.04 LTS virtual machine running on ARM64 architecture, designed to provide secure code execution capabilities while maintaining strict isolation from the host system.

---

System Overview

Operating System

• Distribution: Ubuntu 22.04.5 LTS (Jammy Jellyfish)
• Kernel: Linux 6.8.0-90-generic (PREEMPT_DYNAMIC)
• Architecture: aarch64 (ARM64)
• Hostname: claude

Hardware Resources

Resource	Specification
CPU	4 ARM64 cores @ 48 BogoMIPS each
RAM	3.8 GiB total, ~2.8 GiB available
Swap	None configured
Root Disk	10 GB NVMe (nvme0n1)
Session Disk	10 GB NVMe (nvme1n1)

CPU Features

The ARM64 processor includes advanced features such as hardware cryptographic acceleration (AES, SHA1, SHA2, SHA3, SHA512), atomic operations, pointer authentication (PACA/PACG), and branch target identification (BTI) for security.

---

Sandboxing Architecture

Bubblewrap (bwrap) Isolation

The container uses Bubblewrap as its primary sandboxing mechanism. Key isolation features include:

• Network Isolation: --unshare-net creates a separate network namespace
• PID Isolation: --unshare-pid provides process namespace isolation
• Die-with-parent: Container terminates when parent process exits
• New Session: Prevents terminal hijacking attacks

Seccomp Filtering

The environment employs strict seccomp (Secure Computing Mode) filtering:

• Seccomp Mode: 2 (filter mode)
• Active Filters: 2 seccomp filters applied
• NoNewPrivs: Enabled (prevents privilege escalation)
• Capabilities: All capabilities dropped (CapEff = 0)

A custom BPF (Berkeley Packet Filter) program at /usr/local/lib/node_modules_global/lib/node_modules/@anthropic-ai/sandbox-runtime/vendor/seccomp/arm64/unix-block.bpf enforces syscall restrictions.

Network Proxy Architecture

All network traffic is proxied through local tunnels:

Protocol	Proxy
HTTP/HTTPS	http://localhost:3128
SOCKS5	socks5h://localhost:1080
FTP/GRPC	socks5h://localhost:1080

socat processes forward traffic through Unix sockets to the host:

• HTTP: /tmp/claude-http-*.sock
• SOCKS: /tmp/claude-socks-*.sock

---

Filesystem Layout

Disk Partitions

Device	Mount Point	Size	Usage	Filesystem
nvme0n1p1	/	9.6G	75%	ext4
nvme0n1p15	/boot/efi	98M	7%	vfat
nvme1n1	/sessions	10G	<1%	ext4

Session Directory Structure

/sessions/brave-loving-maxwell/
├── .bash_logout
├── .bashrc
├── .profile
├── mnt/
│   ├── .claude/          # Claude configuration
│   ├── .skills/          # Available skill modules
│   │   └── skills/
│   │       ├── algorithmic-art/
│   │       ├── canvas-design/
│   │       ├── docx/
│   │       ├── pdf/
│   │       ├── pptx/
│   │       ├── skill-creator/
│   │       └── xlsx/
│   ├── outputs/          # User-accessible output directory
│   └── uploads/          # User file uploads
└── tmp/                  # Temporary files

BindFS Mounts

Several directories use bindfs to map host filesystem locations with controlled permissions:

• /sessions/brave-loving-maxwell/mnt/.skills (927G available - host disk)
• /sessions/brave-loving-maxwell/mnt/outputs (user's workspace folder)
• /sessions/brave-loving-maxwell/mnt/uploads (uploaded files)
• /sessions/brave-loving-maxwell/mnt/.claude (configuration)

---

Installed Software

Development Tools

The environment includes approximately 1,201 packages. Key development tools:

Tool	Version
Python	3.10.12
Node.js	22.21.0
npm	10.9.4
pip	22.0.2
GCC	11.4.0
Java (OpenJDK)	11.0.29

Note: Go, Rust, and Docker are not available in this environment.

Snap Packages

• core20 (versions 2683, 2690)
• lxd (version 36562)
• snapd (versions 25585, 25939)

---

Process Architecture

Running Processes

PID	Process	Description
1	bwrap	Bubblewrap sandbox orchestrator
2	bash	Shell wrapper managing proxy daemons
3	socat	HTTP proxy forwarder (port 3128)
4	socat	SOCKS proxy forwarder (port 1080)
5	claude	Main Claude Code agent process

The main Claude process runs with the claude-opus-4-5-20251101 model and has access to specific allowed tools: Task, Bash, Glob, Grep, Read, Edit, Write, and more.

MCP (Model Context Protocol) Servers

Two MCP servers are configured:

1. Claude in Chrome - Browser automation capabilities
2. b89c1e3a-f5c6-4dec-9d8a-0b3db0a78353 - Cloudflare integration

---

Resource Limits

Limit	Value
Open Files	524,288
Max User Processes	14,813
Stack Size	8 MB
Max Locked Memory	8 MB
CPU Time	Unlimited
Virtual Memory	Unlimited
File Size	Unlimited

---

User and Permissions

Current User

• Username: brave-loving-maxwell
• UID/GID: 1002:1002
• Home: /sessions/brave-loving-maxwell
• Shell: /bin/bash

Permission Model

• User runs with zero capabilities
• NoNewPrivs flag prevents privilege escalation
• Seccomp filters restrict available syscalls
• Network access only via controlled proxies

---

Security Analysis

Strengths

1. Multi-layer Isolation: Combines namespace isolation, seccomp filtering, and capability dropping
2. Network Control: All traffic proxied and monitorable
3. Ephemeral Sessions: Filesystem resets between tasks (except workspace folder)
4. No Root Access: User has no elevated privileges
5. Die-with-parent: Ensures cleanup on session termination

Architecture Diagram

┌─────────────────────────────────────────────────────────┐
│                     Host System                          │
│  ┌───────────────────────────────────────────────────┐  │
│  │              Bubblewrap Sandbox                    │  │
│  │  ┌─────────────────────────────────────────────┐  │  │
│  │  │            Ubuntu 22.04 VM                   │  │  │
│  │  │  ┌────────────────────────────────────────┐ │  │  │
│  │  │  │         Claude Code Agent              │ │  │  │
│  │  │  │  - Opus 4.5 Model                      │ │  │  │
│  │  │  │  - Tool Access (Bash, Read, Write...)  │ │  │  │
│  │  │  └────────────────────────────────────────┘ │  │  │
│  │  │                     │                        │  │  │
│  │  │  ┌─────────┐   ┌────┴────┐   ┌───────────┐  │  │  │
│  │  │  │ socat   │   │ socat   │   │ Session   │  │  │  │
│  │  │  │ :3128   │   │ :1080   │   │ Storage   │  │  │  │
│  │  │  └────┬────┘   └────┬────┘   └───────────┘  │  │  │
│  │  └───────┼─────────────┼───────────────────────┘  │  │
│  └──────────┼─────────────┼──────────────────────────┘  │
│             │             │                              │
│      Unix Socket    Unix Socket                          │
│             │             │                              │
│         HTTP Proxy    SOCKS Proxy                        │
└─────────────────────────────────────────────────────────┘

---

Conclusion

This container environment represents a thoughtfully designed sandbox for AI-assisted computing. It balances functionality (full development toolchain, file manipulation, network access) with security (strict isolation, capability dropping, traffic monitoring). The ephemeral nature of the session filesystem combined with persistent workspace folders provides both safety and utility for end users.

The environment is specifically optimized for the Claude Code agent, providing the tools necessary for code execution, file creation, and web access while maintaining strong isolation boundaries to protect both the user's system and the broader infrastructure.

sandbox.txt

⏺ Cowork Sandbox Implementation Found!

  The Cowork feature runs tasks in a Linux VM using Apple's Virtualization framework. Here's the architecture:

  Key Components

  1. Swift Native Module (@ant/claude-swift)
  Sources/ClaudeSwift/VirtualMachine/
  ├── ClaudeVMManager.swift        # Main VM lifecycle management
  ├── ClaudeVMDaemonRPCClient.swift # RPC communication with VM
  └── NAPIBindings+VM.swift        # Node.js bindings

  2. VM APIs Exposed to JavaScript
  - createVM(bundlePath) - Create a new VM instance
  - startVM(bundlePath) - Start the VM
  - stopVM() - Stop the VM
  - vmIsProcessRunning() - Check process status
  - vmLoadTranscripts() - Load conversation transcripts
  - vmShowDebugWindow() / vmHideDebugWindow() - Debug UI

  3. VM Bundle
  - Downloaded from: https://downloads.claude.ai/vms/linux/806dcd93770a30eea36beb50f93c003bb170bce9
  - Contains: rootfs.img (Linux root filesystem)
  - SHA256: 7b37979ec7658579463ca3b057f2bd3ed0247e13d014cdeaebf31f329dadc154
  - Session disk: 10GB sparse disk image for persistence

  4. Requirements
  - macOS 13.0 or later
  - Apple Silicon (arm64) only
  - Uses VZVirtualMachine (Apple Virtualization Framework)

  How It Works

  1. When you start a Cowork task, the app downloads/loads the Linux VM bundle
  2. A Linux VM is started using Apple's native virtualization
  3. Tasks execute inside the isolated Linux environment
  4. The VM has network access (vmOnNetworkStatus)
  5. Results are communicated back via RPC (ClaudeVMDaemonRPCClient)

  The actual task execution logic and Cowork UI are served from claude.ai, but the sandbox runtime is this local Linux VM.

This was from telling Claude Code to dig around in the /Applications/Claude.app directory to figure out how the sandbox worked.

The larger markdown report came from running this prompt inside Cowork itself:

Write a detailed report about the Linux container environment you are running in

cool read

Thanks for posting

https://github.com/kill136/claude-code-open A small exploration during the holidays - this is a reverse-engineered version of the latest Claude Code source code. Interested students can check it out. It's the kind that actually runs, with a reverse engineering completion rate of 92%. @simonw

Nice. Thanks again for sharing

bubblewrap is awesome. it's honestly super sick to see a company like Anthropic using these wonderful OSS tools too!!! also appreciate you digging into the VM

Shouldn't bubblewrap be inside ubuntu?

extract the prompt for all these skills , would be nice to see

nice writeup

Great review of the app. Also kudos for getting Claude to dig into Claude.

For those curious about comparison btw Anthropic, Vercel, and Cloudflare:

Anthropic

• bubblewrap (OS-level primitives) for Claude Code CLI
• they open-sourced it: sandbox-runtime
• gVisor (userspace kernel) for Claude web

Vercel

• Firecracker (microVMs) for their Sandbox product, and also built just-bash — a simulated shell in TypeScript with no real OS at all

Cloudflare

• Durable Object their Sandbox product
• However, they launched Dynamic Worker Loading for untrusted one-off code execution. Workers use Isolates, not Container.
  -> so I asked Kenton (a creator of Worker) "When should I use which one?"

Source: ClaudeAI subreddit, Michaelliv's blog post

Sweet PoC for deep diving into other apps. Thx.

Did an analysis for windows (from outside):

How Claude Code on Windows Runs Code

The Short Answer

Claude Desktop on Windows runs code inside a Hyper-V lightweight VM running Linux. This is the Windows equivalent of what macOS does with Apple's Virtualization framework.

Architecture Breakdown

1. The VM Bundle (vm_bundles/claudevm.bundle/)

File	Size	Purpose
vmlinuz	~15 MB	Linux kernel 6.8.0-94-generic (Ubuntu 22.04 build)
initrd	~175 MB	Initial ramdisk with boot environment
rootfs.vhdx	~10 GB	Root filesystem (VHDX = Hyper-V native disk format)
sessiondata.vhdx	~2.5 GB	Ephemeral session storage
smol-bin.vhdx	~37 MB	Small utilities disk, shipped with the app installer

The VHDX format is the giveaway - it's Microsoft Hyper-V's native virtual hard disk format.

2. The Service (cowork-svc.exe)

A Windows PE64 executable shipped in the app resources at:

C:\Program Files\WindowsApps\Claude_1.1.2685.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

This manages the VM lifecycle via Windows' Host Compute Service (HCS) APIs. The logs show:

• [VM:start] Configuring Windows VM service...
• [VM:start] Windows VM service configured
• Guest connection polling, keepalive pings, process spawning via RPC

3. Startup Sequence (from cowork_vm_node.log)

1. Download bundle files (rootfs.vhdx.zst, vmlinuz.zst, initrd.zst) - compressed with zstd, verified by checksum
2. Copy smol-bin.vhdx from the app installation into the bundle
3. Configure and start the Windows VM service via cowork-svc.exe
4. Wait for guest connection (~10-16 seconds)
5. Check network connectivity, then API reachability
6. Install the Claude Code SDK (claude-code-vm/2.1.34/claude - an ELF x86-64 Linux binary) into the VM
7. Total startup: ~16 seconds on first boot, faster on subsequent

4. Per-Session Execution

Each conversation spawns a process inside the VM:

cmd=/usr/local/bin/claude
cwd=/sessions/ecstatic-nice-hamilton
mounts=5 (outputs, .claude, .skills, .local-plugins, uploads)

Sessions get Docker-style random names (ecstatic-nice-hamilton, determined-fervent-babbage, etc.) and isolated /sessions/<name> working directories with selective mounts.

5. Network & Auth

• OAuth tokens are proxied through a MITM proxy inside the VM (OAuth token approved with MITM proxy)
• Keepalive pings every 2 seconds to monitor VM health
• Network status transitions: NOT_CONNECTED -> CONNECTED -> API REACHABLE

Mac vs Windows Comparison

Aspect	macOS	Windows
Hypervisor	Apple Virtualization.framework	Windows Hyper-V (HCS)
Native module	@ant/claude-swift (Swift)	cowork-svc.exe + TypeScript vmClient
Disk format	Raw .img files	.vhdx (Hyper-V native)
Kernel	ARM64 Linux	x86-64 Linux 6.8.0-94-generic
Inner sandbox	Bubblewrap + seccomp	Unknown (no bwrap/seccomp in logs)
App packaging	DMG	MSIX (Microsoft Store)

Historical Note

Logs show an interesting transition. Before ~Feb 10, 2026, the Windows app repeatedly tried to load @ant/claude-swift (the macOS module) and failed, logging yukonSilver not supported. On Feb 10 it switched to the new TypeScript-based vmClient module that works with cowork-svc.exe and VHDX disks. That's when Windows cowork VM support actually shipped.

What About WSL2?

The Claude Code CLI (invoked from a terminal) runs directly in whatever environment you launch it from - in this case WSL2 (kernel 6.6.87.2-microsoft-standard-WSL2, Ubuntu 24.04). That's separate from the cowork VM. The cowork VM is specifically for the Claude Desktop app's built-in "Claude Code" feature (the GUI version).

Key Files

%AppData%\Claude\
├── vm_bundles\claudevm.bundle\    # VM disk images and kernel
│   ├── vmlinuz                    # Linux kernel
│   ├── initrd                     # Initial ramdisk
│   ├── rootfs.vhdx                # Root filesystem
│   ├── sessiondata.vhdx           # Session storage
│   └── smol-bin.vhdx              # Utilities disk
├── claude-code-vm\2.1.34\claude   # ELF x86-64 binary (runs inside VM)
├── claude-code\2.1.34\claude.exe  # Windows native binary (runs on host)
└── logs\
    └── cowork_vm_node.log         # VM lifecycle logs

References

• Simon Willison's macOS analysis

and from inside cowork:

I'll gather system info in parallel.Let me grab a few more details.Here's the full breakdown:

Virtualization Layer

This is a Hyper-V VM (not a container), confirmed by systemd-detect-virt returning microsoft. It's running a full Ubuntu 22.04.5 LTS (Jammy) with systemd as PID 1 — a proper VM, not a lightweight container like Docker/LXC. The boot cmdline shows console=ttyS0 with serial console, typical of cloud/hypervisor VMs.

Kernel: 6.8.0-94-generic — an HWE (Hardware Enablement) kernel backported from Ubuntu 24.04, compiled with PREEMPT_DYNAMIC.

Hardware (Virtual)

• CPU: 2 vCPUs, Intel i5-9600KF @ 3.70GHz (host CPU passed through). Has AVX2, AES-NI, SSE4.2. The hypervisor flag confirms virtualization.
• RAM: 3.8 GiB total, ~610 MiB used, no swap.
• Disk: 3 block devices:
  • sda (10G) — root filesystem, ext4, 81% used (7.7G of 9.6G)
  • sdb (16M, read-only) — likely metadata/config
  • sdc (10G) — mounted at /sessions, ext4, separate data disk for session workspaces

Network

• eth0: 172.16.0.127/24, gateway 172.16.0.1 — private RFC1918 subnet
• DNS: 100.100.100.100 — custom internal resolver (common in cloud/Tailscale setups)
• Listening: SSH on port 22, systemd-resolved on 53 (loopback only)
• Active outbound TCP connections to external IPs on port 443 (HTTPS) — API calls

User & Process Model

Running as a dedicated unprivileged user relaxed-tender-clarke (UID 1010). The session name is used as the username — each Cowork session gets its own user. Home directory is /sessions/relaxed-tender-clarke/.

The namespaces are all default (init namespace IDs) — no user namespacing or PID namespacing beyond the VM itself. Security is at the VM boundary, not namespace-level.

Key Services

• coworkd.service — vsock RPC bridge for process management (the host↔VM communication channel)
• sdk-daemon (/usr/local/bin/sdk-daemon) — the Anthropic SDK daemon managing MCP connections
• Claude Code process (/usr/local/bin/claude) — the main agent process (~460 MiB RSS), launched with --model claude-opus-4-6, stream-json I/O, and a pile of MCP server configs (Asana, Figma, Sentry, Google Calendar, Gmail, Chrome, Mattermost, etc.)
• Standard Ubuntu services: sshd, snapd, cron, rsyslog, packagekit

Filesystem Layout

• /sessions/ — separate ext4 disk (sdc), contains per-session user homes
• /sessions/<name>/mnt/ — workspace mount point (uploads, outputs, skills, plugins, .claude/ config)
• /sessions/<name>/tmp/ — session-scoped temp directory
• /smol/ — unknown, likely internal tooling
• 6 snap loop mounts (core20, lxd, snapd) — standard Ubuntu snap infrastructure
• ~1214 dpkg packages installed

Installed Toolchain

Python 3.10.12, Node.js 22.22.0, GCC 12, Java (OpenJDK), Ruby. No Go. npm available with a custom global prefix at /usr/local/lib/node_modules_global.

Resource Limits

Generous: 524K open files, unlimited CPU/memory/address space, 14963 max processes. No cgroup resource constraints visible — the VM itself is the isolation boundary.

Architecture Summary

The design is: one Hyper-V VM per Cowork session, with a dedicated user, a separate data disk for session state, and coworkd bridging vsock RPCs to the host. The Claude Code process runs as the session user with MCP servers connected via SDK transport. The VM image is a fairly standard Ubuntu 22.04 with snap support and a pre-installed dev toolchain. Security model relies on VM-level isolation rather than container namespacing.