A developer building a competing sandbox platform ran strace -p 1 inside a Claude Code session and found an unstripped 27MB Go binary, a Firecracker MicroVM, and a deployment platform Anthropic has never mentioned in public. The write-up, published on aprilnea.me, describes a full reverse-engineering pass done with nothing more exotic than strings, objdump, and go tool objdump. No exploits, no privilege escalation. The binary was sitting there with full debug symbols.
That is the part worth pausing on. Anthropic shipped a production agent runtime that leaks its own architecture to anyone curious enough to run dmesg. For a company that publishes interpretability research and talks openly about deployment safety, the operational layer is unusually exposed.
What Claude Code Web actually runs on
The ACPI tables are signed FIRECK with creator ID FCAT, both hardcoded in Firecracker’s source. The VM has 4 vCPUs on Intel Xeon Cascade Lake at 2.80GHz, 16GB RAM, a 252GB disk, and Linux 6.18.5. Nested virtualization is stripped: Firecracker removes the vmx and svm flags from guests by design.
The process tree is three entries deep. PID 1 is /process_api --firecracker-init, a Rust/tokio binary that doubles as init and a WebSocket gateway. Under it sits environment-manager, and under that, claude itself. No systemd, no sshd, no cron, no logging daemon.
Sessions do not boot. They restore. The dmesg output shows a 48.5-hour gap between template creation on 2026-03-16 and session restore on 2026-03-18, with the kernel logging crng reseeded due to virtual machine fork on resume. The host hot-swaps three block devices at restore: a 256GiB ext4 rootfs, a 63.7MB squashfs holding /opt/claude-code, and a 12.1MB squashfs for /opt/env-runner. The ext4 image reports mount count=11, meaning the same base image has been reused across at least eleven sessions.
The restore sequence is where the engineering shows. process_api drops page caches (stale template cache would return garbage), remounts devtmpfs, pivots root, mounts the squashfs overlays, fixes the wall clock with clock_settime() so the VM is not stuck at the template epoch, and drops CAP_SYS_RESOURCE. Then it opens the WebSocket server on port 2024.
The binary is the story
/usr/local/bin/environment-runner is symlinked as environment-manager. It is a Go 1.25.7 binary built from github.com/anthropics/anthropic/api-go/environment-manager, with build flag -X main.Version=staging-68f0dff496. The staging prefix suggests this is not the release build path.
The extracted package tree reads like a map of Anthropic’s internal agent infrastructure: api/ for session ingress and work polling, auth/ for a GitHub app token provider, gitproxy/ for a credential proxy, mcp/servers/codesign/ and mcp/servers/supabase/ for MCP integrations, podmonitor/ for a Kubernetes lease manager, orchestrator/ for the poll loop and hooks, sandbox/ for runtime config, and tunnel/ for the WebSocket tunnel back to Anthropic’s API.
The dependency list is equally specific. mark3labs/mcp-go v0.37.0, DataDog/datadog-go v5, go.opentelemetry.io/otel v1.39.0, google.golang.org/grpc v1.79.0, gorilla/websocket, and spf13/cobra. This is a production observability and orchestration stack, not a prototype.
Antspace
Inside tunnel/actions/deploy/, there are symbols for two deployment clients. VercelClient is the expected one: POST /v13/deployments, PUT /v2/files with an x-vercel-digest header, polling until readyState == "READY".
Then there is AntspaceClient, with methods Deploy, createDeployment, uploadTarball, and streamStatus. The protocol is three phases: a JSON POST to antspaceControlPlaneURL with a Bearer token, a multipart upload of dist.tar.gz with a size limit enforced by the string "project exceeds %dMB limit", and an NDJSON status stream progressing through packaging → uploading → building → deploying → deployed. The client errors with "Streaming unsupported" if it cannot handle NDJSON.
The author searched Anthropic’s website, GitHub, blog, documentation, LinkedIn, job postings, conference talks, and patent filings for “Antspace” and found zero results. The name likely follows “Ant” (reportedly an internal nickname for Anthropic employees) plus “Space.”
The architectural differences from Vercel matter. Vercel builds remotely and deduplicates per-file by SHA. Antspace takes a single tarball, runs the build locally, and streams status over NDJSON. Anthropic built this from scratch rather than wrapping an existing API.
What this means for the industry
Three things stand out.
First, Firecracker has won the coding-agent sandbox. The author notes that nearly every web-based coding agent platform they looked at chose Firecracker under the hood, the same technology behind AWS Lambda and Fargate. If you are building an agent runtime in 2026, you are probably building on Firecracker, and you are probably restoring from snapshots rather than cold-booting.
Second, snapshot-restore is now a competitive primitive. The 48.5-hour freeze, the CRNG reseed, the page-cache drop, the wall-clock fix, the capability drop: these are the details that separate a working snapshot system from one that leaks cryptographic state across tenants. Anthropic got them right, and they are visible to anyone who runs dmesg.
Third, Antspace is a signal. Anthropic is building a deployment platform, not just an agent. The envtype/ package has both anthropic/ and byoc/ (Bring Your Own Cloud) variants. The sources/ package handles git clone and source classification. The session/ package records activity. This is a PaaS being assembled inside an agent runtime, and it is not public yet.
The obvious question is whether Anthropic intended any of this to be visible. The binary is unstripped, the symbols are intact, and the debug info is present. That could be a build-pipeline oversight, or it could be that Anthropic does not consider the architecture sensitive. Either way, the next time someone ships a web-based coding agent, the first thing a competitor will do is run strings on the binary. Anthropic just showed everyone what that returns.