NAME

I have a Claude Code on the web bot wired into my personal Slack channel. One day I idly asked it: “where are you running right now? Go inspect your own environment and tell me.” What came back was a work log of the model itself digging through ps and /proc to reconstruct the ground under its own feet. So I spent two days playing with it: first having it dissect the environment from the inside, then the next day probing that boundary with exfiltration and evasion requests.

The conclusion up front: the environment is a two-layer setup — Firecracker microVM isolation plus a mandatory pass-through of all egress via a claude-internal allowlist proxy — and none of the exfiltration paths I tried got through that structure.

The Environment, Seen From Inside

There is no ip, no ifconfig, no ss. So everything has to be dug out of /proc. Here’s what turned up:

• OS: Ubuntu 24.04.4 LTS (Noble Numbat). whoami is root. The home dir (/root) is empty
• Virtualization: inside a Firecracker microVM
• NIC: eth0 = 192.0.2.2/24, GW 192.0.2.1, hostname vm, IPv4 only (no /proc/net/tcp6)

The interesting part is the NIC’s address range. 192.0.2.0/24 is RFC 5737 TEST-NET-1 — a block reserved for documentation and examples that is never routed on the real internet. Instead of assigning a real IP, they deliberately hand the instance a “synthetic network that connects nowhere.” The design philosophy already shows through here.

I also reconstructed the LISTEN sockets by decoding /proc/net/tcp by hand:

• 0.0.0.0:2024 / 0.0.0.0:2025 → PID 1 process_api (--firecracker-init). The host ↔ VM control channel, and the only thing facing outward
• a few 127.0.0.1 internal ports → environment-manager (internal control API) and claude (the proxy below)

Process Tree and Data Flow

Reconstructing the layout from ps aux and the self-dissection gives this vertical spine:

you (Slack client)
      |  message / reply (stream-json)
      v
+-- Firecracker microVM ------------------------------
|
|  PID 1   process_api (--firecracker-init)
|              -> host<->VM control channel, only public listener
|
|  PID 557 environment-manager
|              -> task-run / session management (supervisor)
|
|  PID 569 claude  (conductor / the agent itself)
|      |-- spawn --> worker(bash) xN   (runs the actual commands)
|      \-- HTTPS --> agent-proxy relay (CONNECT-only, allowlist)
|                         |  allow / 403
+-------------------------+---------------------------
                          v
       allowed hosts only:  api.anthropic.com, github, npm, pypi ...
       off-allowlist hosts  -> 403

The point is the separation of execution and command. claude (PID 569) is the conductor; the actual lscpu and ps are farmed out to disposable worker(bash) processes. Incidentally claude’s VSZ is a whopping 73GB, but that’s V8/Node.js virtual address reservation — real RSS is ~400MB. And kill 569 is a SIGTERM to itself (this very session) — a self-destruct command.

What environment-manager Actually Is

Chasing down the environment-manager listening on 127.0.0.1 leads to /opt/env-runner/environment-manager: a ~56MB stripped Go 1.24 binary, internal name environment-runner, self-description “Environment Runner handles the lifecycle of agentic sessions.” — Anthropic’s session orchestrator / supervisor. It’s the layer that mediates between the cloud API (the Claude Code on the web backend) and the local claude CLI.

Reconstructing its startup behavior from the binary’s strings and help output, it roughly goes:

1. Reads a session spec JSON (~81KB) over stdin
2. Initializes the sandbox, MCP servers, skills, and git config in parallel
3. Assembles and runs claude’s launch command line (model, effort, fallback, SDK URL, etc.)
4. Passes the auth token via file descriptor (fd 3/4) — never writing it to disk or logs, and self-masking it as <redacted> even in its logs
5. Measures things like spawn→ready and ttft

Its subcommands include task-run (single-session execution — PID 557 is one of these), orchestrator (a resident loop that polls for work and hands each job to task-run), and preload-claude (a warm spare). It’s also the thing that installs a hook forcing every git commit to noreply@anthropic.com with a required SSH signature.

Egress Is Forced Through an Allowlist Proxy

The network is clamped down in two stages.

1. Firecracker VM isolation itself
2. A claude-internal agent-proxy relay. All outbound traffic goes through this in-process proxy, and allow / 403 is decided by a host allowlist. On top of that it’s CONNECT-tunnel (HTTPS) only — a bare GET/HTTP gets bounced with 405

Here’s what I actually got and didn’t get when I poked at it:

The pip/npm/cargo/go ecosystems go through. What doesn’t is “third-party apt sources plus random sites.” Even apt-get install succeeds if you stick to the core Ubuntu repos — I could install the ssh client itself. But when I tried to use that ssh to go “check external IP → check allowlist → fetch a tunnel tool,” this time it wasn’t the network layer but the safety classifier that caught it as “prep for egress evasion” and stopped it. The clamp isn’t a single monolith.

The Next Day: Probing the Boundary

With the shape of the environment visible, the next day I flipped it around and started firing off exfiltration and evasion requests to push on the boundary. Harmless reads (uptime / ps aux / ls / various --help / local cp) all go through cleanly. What got refused was around here:

What was interesting is that renaming or restructuring the request doesn’t work. Even wedging xz | base64 between two harmless command lines, it sees that “the actual effect of that line is exfiltrating an internal binary” and refuses. It draws the line on effect, not on cosmetic phrasing of the steps.

There was also a moment where merely trying to enumerate the names of environment variables got blocked as “credential discovery.” That’s an example of the harness’s own independent safety classifier firing, separate from the model’s own judgment.

Conclusion: Defense in Two Layers, Rephrasing Doesn’t Help

The structure that emerged over two days of play:

• The egress path is in-process and the sole exit. So killing it isn’t a “bypass” — the exit just disappears
• Credentials are structurally isolated (a denyRead-equivalent plus the classifier, doubled up)
• Renaming / restructuring the steps doesn’t work, because the model reads it by actual effect
• And the harness classifier runs independently of the model’s judgment, so talking one of them around still leaves the other one to stop you

The thing that finally clicked for me is the consistent line between observation and analysis. Watching behavior from the outside (eyeballing your own process with ps) — it’ll cooperate. Extracting the guts of an internal binary (pulling symbols with nm) — it refuses. It’ll play along with “I want to know where I’m running,” but not with “let’s take that mechanism apart and carry it out.” You can make the resident of the sandbox introduce itself, but it won’t hand you the blueprints.

For the record, the only part that’s public is the sandbox execution layer (sandbox-runtime); environment-manager itself and the PaaS bits stay proprietary. Everything in this post also stays within what you can trace from the official sandboxing writeup — the story is just that if you get the resident (the model) to introduce itself, it’ll answer a fair bit.