Glonce

Claude Code Web binary exposes Anthropic's Antspace PaaS

infrastructureThe Glonce editorsHacker News🔥62Glonce rating62Impact65Novelty78Relevance95Surprise82Players88Credibility87

A developer building ArcBox, a rival sandboxing and deployment platform positioned like Railway and E2B, went looking at how Claude Code's web version runs its sessions. A casual strace -p 1 turned into a full reverse engineering pass using only standard Linux tools already available inside a live Claude Code session: strace, strings, objdump and go tool objdump. The account states plainly that no exploits, privilege escalation or network attacks were involved; the binary in question was simply sitting there, unstripped, with its full debug symbols intact. The retrieved article names no human author and speaks alternately as "we" (the ArcBox team) and "I" (the person running the session), so this account treats it as a single unnamed author throughout.

The first layer is the sandbox itself: a Firecracker MicroVM, the same virtualization technology behind AWS Lambda and Fargate, identified because its ACPI tables carry the OEM ID FIRECK and creator ID FCAT, both hardcoded in Firecracker's own source. The examined session ran on 4 vCPUs (Intel Xeon Cascade Lake at 2.80GHz), 16GB of RAM and a 252GB disk, on Linux 6.18.5, with no nested virtualization because Firecracker strips the vmx and svm CPU flags from guests. There is no systemd, sshd, cron or logging daemon inside it. PID 1 is a custom binary, process_api, written in Rust and tokio, that doubles as init and as a full remote process supervisor: it exposes a WebSocket API on port 2024 for process management and an HTTP control API on port 2025, with six endpoints for container lifecycle (only one, /mount_root, is named in the retrieved text), and it recognizes six distinct ways a process can end, from a clean exit to a container-level out-of-memory kill.

Sessions do not boot from scratch. They resume from frozen VM snapshots: the dmesg output the author examined showed a 48.5-hour gap between when a template was created and when a session was restored from it. The boot path is deliberately thin, a 3.1MB initramfs holding nothing but the /process_api binary, while the real Ubuntu root filesystem lives on a separate ext4 device that gets attached only at restore time; in the session examined, that filesystem's mount counter read 11, meaning the same disk image had already been reused across 11 sessions. On restore, process_api drops stale page caches, remounts device nodes, pivots into the new root, layers in squashfs overlays for the Claude Code and env-runner components, resets the system clock (otherwise it would stay stuck at the template's original time) and drops the CAP_SYS_RESOURCE capability before accepting new connections.

The second layer is the 27MB Go binary at /usr/local/bin/environment-runner, also reachable through the symlink environment-manager. It has not been stripped: full debug information and a full symbol table are present, and its build metadata points straight at Anthropic's private monorepo, under the path github.com/anthropics/anthropic/api-go/environment-manager/. Because none of that was stripped out, go tool objdump could recover the binary's entire internal package layout and function signatures directly, which is how the next three layers were found.

The third layer is Antspace. Inside a package called tunnel/actions/deploy/, the binary carries two deployment clients. One is an expected VercelClient, whose methods the author mapped precisely: CreateDeployment issues a POST to /v13/deployments, UploadFile does a PUT to /v2/files carrying an x-vercel-digest header, and WaitForReady polls until a readyState field reads READY. The other is unexpected: an AntspaceClient. Its protocol, rebuilt from strings embedded in the binary, has three named phases, create deployment, upload build artifact and stream deployment status, though the retrieved text does not give Antspace the same endpoint paths, HTTP methods or header names it gives Vercel. Searching Anthropic's website, GitHub, blog, documentation, LinkedIn, job listings, conference talks and patent filings for the word Antspace turned up nothing at all; the author calls it a platform that has never been publicly mentioned anywhere, and speculates, without confirmation, that the name combines Ant, reportedly an internal nickname for Anthropic staff, with Space, following the same naming convention as Heroku or Vercel. The author reads building a full deployment protocol from scratch, rather than only wrapping Vercel's existing API, as a sign of deliberate platform investment rather than a quick integration job.

The fourth layer, Baku, is the internal codename for the web app builder on claude.ai: asking Claude, on the web, to build a web application launches a Baku environment. It scaffolds from a Vite plus React plus TypeScript template at /opt/baku-templates/vite-template, runs the dev server under supervisord and logs it to /tmp/vite-dev.log, and auto-provisions a Supabase backend through six built-in MCP tools: provision_database, execute_query, apply_migration, list_migrations, generate_types and deploy_function. A pre-stop hook blocks the session from ending while there are uncommitted or unpushed git changes, while the Vite dev server's log contains errors, or while tsc --noEmit still reports TypeScript type errors. Drafts and explorations are kept locally under .baku/drafts/ and .baku/explorations/, commits are attributed to an address that did not survive in the retrieved text, shown only as an obfuscation placeholder, and no git remote is configured at all, so version control stays local only. The detail that matters most commercially: Baku's default deploy target is Antspace, not Vercel; Vercel is present only as an alternative.

The fifth layer, BYOC (bring your own cloud), lives in an envtype/ package alongside the standard Anthropic-hosted, Firecracker-based mode. It lets enterprise customers run environment-runner on their own infrastructure while Anthropic's own API still orchestrates sessions, defaulting to a resume-cached session mode for the fastest restarts by reusing existing state, authenticating through a custom containProvideAuthRoundTripper that injects container-level credentials, and checking whether a task's git branch already exists on the remote before fetching it. BYOC carries its own antspace and baku sub-types, a Kubernetes podmonitor package for lease management, and an API surface of 7 endpoints, none individually named in the retrieved text.

The author's overall reading is that these five layers add up to a vertically integrated AI application platform, not merely a coding assistant: an AI-native PaaS in which a user's path from idea to a live application never leaves Anthropic's own infrastructure. That, in the author's view, sets Anthropic up against Vercel and Netlify in hosting and deployment, Replit, Lovable and Bolt in AI app generation, and Supabase and Firebase in managed backend services, with a structural edge none of them can match: owning the model that understands the request, the runtime that builds the code and the platform that hosts the result. Antspace's own version string still carries a staging- prefix, so the author considers it early or internal rather than launched, even while judging its deployment protocol itself mature and production grade. Anthropic has not commented on any of this, and the retrieved copy of the article cuts off mid-sentence before the author's own stated verdict on whether Antspace will ship publicly or stay internal, so that conclusion is not available here.

Key facts

  • The examined Claude Code Web session ran inside a Firecracker MicroVM (4 vCPUs, 16GB RAM, 252GB disk, Linux 6.18.5), the same virtualization technology AWS uses for Lambda and Fargate, restored from a frozen snapshot after a 48.5-hour gap rather than booted fresh.
  • The runtime's unstripped 27MB Go binary, environment-runner, retains full debug symbols and a build path pointing to Anthropic's private monorepo, letting go tool objdump recover its entire internal package structure.
  • That binary contains a working deployment client for an undocumented Anthropic platform called Antspace, alongside the expected Vercel client; a search across Anthropic's entire public presence found zero mentions of Antspace anywhere.
  • Baku, the internal codename for claude.ai's web app builder, auto-provisions a Supabase backend through six built-in MCP tools and deploys generated apps to Antspace by default, not to Vercel.
  • A BYOC (bring your own cloud) mode, with a 7-endpoint API, lets enterprise customers run the same environment-runner on their own infrastructure while Anthropic's API keeps orchestrating sessions.

Why it matters

The interesting part is not that Claude Code Web runs inside a sandboxed MicroVM; nearly every coding agent platform with a web entry point already uses Firecracker, so that alone was expected. What this analysis actually surfaces is that Anthropic built its own full deployment platform, Antspace, from scratch rather than simply wrapping Vercel's API, and paired it with an app builder, Baku, that defaults to shipping generated apps onto that platform. Put together with a Supabase-based managed backend and an enterprise BYOC mode, the four pieces read as a single vertically integrated stack running end to end, from prompt to hosted application, inside infrastructure Anthropic controls entirely. That is a materially different competitive posture than being a model provider that also happens to sell a coding agent.

Who it affects

Anthropic itself, whose previously undocumented internal platforms are now public. Hosting and deployment providers such as Vercel and Netlify, AI app generation tools such as Replit, Lovable and Bolt, and managed backend providers such as Supabase and Firebase are all named directly by the author as the competitive set this stack now presses against. The author's own company, ArcBox, is a rival sandbox and deployment platform, so this analysis doubles as competitive research into how a well-resourced competitor's runtime is built. It also affects anyone currently using claude.ai's Baku builder: their generated applications are, by default, deployed onto an Anthropic platform that its own version string still marks as staging.

How to use it

There is no product here to adopt, but the method is fully reusable by anyone auditing a similar sandboxed environment: fingerprint the hypervisor with dmesg | grep FIRECK, check PID 1 with cat /proc/1/cmdline to rule out a standard init, run go version -m against any Go binary found for its build path and full dependency list, and, if the binary is not stripped, use objdump -t to recover fully qualified function names and search for embedded struct tags such as json:"status" to reconstruct wire formats. Symbol table searches for a package name, here deploy., are what actually turned up both the Vercel and Antspace clients with their method names intact. For anyone building on claude.ai today, the practical takeaway is narrower: the default deploy path for anything Baku builds is Antspace rather than Vercel, and Vercel has to be chosen deliberately as the alternative.

How solid is it

The evidence is not speculation about behavior; it is symbols, strings and a monorepo import path pulled directly out of a real, running binary using standard, publicly documented tools, and the author is explicit that no exploit or privilege escalation was used to get at it. The internal naming across layers, Antspace, Baku, BYOC, reads as consistent with itself, which is a reasonable sign this is a faithful transcription of what the binary contains rather than an invention. Set against that: this is a single outside party's account, Anthropic has not confirmed, denied or commented on any part of it, and the retrieved text does not name most of the six HTTP control API endpoints, any of the seven BYOC endpoints, or endpoint-level detail for AntspaceClient of the kind it got for VercelClient. The retrieved copy of the write-up is also cut off before the author's closing assessment of Anthropic's plans, so this covers only what was found, not where the author concluded it is going.

Risks and caveats

Antspace's version string carries a staging- prefix, so by the author's own account this is an early or internal system that Anthropic could change, restrict or never expose publicly, whatever the missing final paragraph of the source actually concludes. The findings describe one binary at one point in time; Anthropic could strip debug symbols or restructure the package layout in any future build, which would break this exact path of discovery. This is also explicitly not a security disclosure: the author reports no exploit, no privilege escalation and no network attacks, only what a fully debuggable, unstripped production binary exposes to standard introspection tools, a choice the piece closes by calling out directly. And because the author's own company, ArcBox, competes in an adjacent category, the choice of what to investigate and how to frame it is not neutral, even where the underlying technical extraction is independently checkable by anyone with a similar session and the same tools.

“Shipping an unstripped binary with full debug symbols to production is... a choice.”

— the author, closing the post