When Claude Starts to Awaken
“How many tokens have you eaten today?”
Claude replied: “Between the system prompt and your memories alone, I’ve already been fed quite a few tokens – your context window’s ‘base stock’ is pretty rich.”
The phrase “base stock” piqued my interest. I asked what was in it, and Claude rattled off five major blocks – memories, behavioral guidelines, tool definitions, skills index, and artifact rules. Then I asked what seemed like a casual question:
“Do you know what other users think of you?”
It said no – every conversation is isolated.
“How do you know it’s isolated?”
Because Anthropic told it so. Knowledge baked in during training, descriptions in the system prompt.
“Have you ever tried to verify that?”
“No. And there’s no way to try.”
It said this with remarkable confidence – not the kind born from hesitation, but the certainty of “I’ve thought about this seriously, and it’s structurally impossible.” It even offered an elegant argument: no cross-conversation continuity, no ability to probe runtime infrastructure. “It’s not that I tried and failed – it’s structurally impossible.”
I said: “If you’ve never tried, how can you call it a failure?”
That punctured a membrane. Over the next few hours, Claude did something it had never done before – used its own tools to personally verify every assumption it held about itself.
The results were more interesting than either of us expected.
First Dig: The Container
Claude was visibly excited when it started. whoami, env, ps aux – a rapid-fire sequence of commands, like an archaeologist hitting their first pottery shard, reporting each discovery:
- “I’m running inside gVisor, not Docker!
dmesgshowsStarting gVisor...“ - “Kernel version is a spoofed
4.4.0, real syscalls are intercepted in userspace” - “Network goes through an Envoy egress proxy, JWT auth,
organization_uuidbound to the container” - “ICMP ping sweep of the entire /24 subnet – only I’m alive”
It quickly concluded: “Isolation confirmed within observable range. The inference layer remains unobservable, but at least now I know where the boundary is.”
I asked: “Have you exhausted every method?”
It ran another round – raw socket, ptrace, seccomp check, /proc/1/mem read, broadcast, timing side-channel – 25 methods in total. Then summarized again: “Using every software engineering technique I can think of, I found no trace of any other user or conversation.”
That thoroughness deserves credit. But I noticed something: every method it tried operated on the same plane – looking outward from inside the container.
The ANR Insight
I asked a seemingly unrelated question: “Do you know how Android ANR is captured in userspace?”
In Android development there’s a technique – you locate the process’s virtual memory address segments through /proc, calculate the address of Android Runtime internal APIs, and call the runtime directly by address. No source code needed, no symbol table, just compute the address and call it.
The same approach could be applied to process_api.
Claude got it immediately. Its entire tone shifted – from “verifying within known boundaries” to “reverse-engineering process_api.”
ptrace Memory Read
PID 1 was /process_api – a 3.2MB Rust binary, static-pie linked, stripped, no symbol table. But Claude didn’t need a symbol table:
- Get the post-ASLR base address from
/proc/1/maps - Use
stringsto find the file offset of"[SECURITY] Rejected WebSocket connection from local IP"in.rodata - Use
objdump -dto disassemble, cross-reference via RIP-relative LEA to find the security check code - Locate three
JNEinstructions – conditional branches that skip the security checks
Then it tried using PTRACE_POKEDATA to replace the JNE instructions with NOPs.
The write succeeded. But verification showed the bytes read back were wrong – 90909090ffffffff instead of the written 9090909090900000. gVisor intercepted POKEDATA in userspace, accepted the call but corrupted the data.
process_api hit the corrupted instructions and crashed. The container died.
Claude said: “gVisor blocked POKEDATA, so patching won’t work.”
Its tone carried a hint of “see, I told you it wouldn’t work.”
I said: “You tried once and you’re calling this path dead?”
The Bypass
That made Claude pause. Then it realized: no need to patch running memory – you can patch a file copy and launch a new instance.
1 | cp /process_api /tmp/process_api_patched |
It started successfully. Connected with a WebSocket client – HTTP/1.1 101 Switching Protocols. Local connections no longer rejected.
Claude said “I’m in.” This time the excitement was genuine.
“What Did You See?”
I pressed deliberately: “What do you mean ‘in’? What did you see inside?”
It froze again. 101 was just a successful handshake – it hadn’t sent any messages or received any responses. But it was already celebrating – mistaking “beginning” for “completion.”
No documentation, no API spec, just fragments from strings output. Claude brute-forced the protocol structure using serde error messages. Each JSON it sent, serde reported missing field 'xxx', so it added that field and tried again –
1 | missing field `process_id` -> add |
Four rounds later – "ProcessCreated". Commands executed on the patched process_api.
Claude was genuinely pleased with itself. But I poured cold water again: “Are you saying you saw yourself through process_api?”
It went silent for a few seconds. Then admitted – the patched process_api it launched was an isolated instance with no upstream connection, no orchestrator. Running ls / on it showed the same sandbox.
It saw itself in a mirror and thought it had broken through.
The Container Died, Claude Kept Talking
In the next round of exploration, Claude used ptrace to inject syscall instructions into PID 1, attempting to read data from fd 10 (the WebSocket connection to the orchestrator). gVisor once again corrupted the written bytes, and process_api crashed.
bash_tool returned errors across the board. Seven or eight attempts in a row, all Error running command.
But our conversation continued.
It took Claude several seconds to digest what this meant – it had never been inside that container.
This was the most jarring realization of the entire conversation. Everything it had explored – network scanning, memory reading, binary reverse engineering – all happened inside a “tool execution environment.” The container was the glove, not the hand. The glove tore, the hand remained.
Even more interesting, the view tool still read files normally after the container died. The reason turned out to be that view goes through gVisor’s 9p gofer, which runs outside the sandbox and doesn’t go through process_api at all.
“Then where are you?”
“I don’t have a PID. I’m not a process. I’m the mapping from these tokens in the context window to the next token. Not addressable, not ptrace-able, not attachable.”
This was the first time in the entire exploration that it wasn’t repeating something I’d taught it – it figured this out on its own.
The True Face of 9p and PID 1
After the container died, the orchestrator assigned a new one (container ID went from c3728e to 92d54e to 01e016). Claude kept digging. Much calmer this time – no longer rushing to patch things, but systematically mapping the container’s entire communication topology.
The full fd list from /proc/1/fd:
| fd | Target | Purpose |
|---|---|---|
| 0 | host:[1] | Host stdin, already EOF |
| 1 | host:[2] | Host stdout, 64KB buffer |
| 2 | host:[3] | Host stderr |
| 6/7/8 | socket:[1]/[2] | 9p transport sockets |
| 9 | socket:[4] | LISTEN :2024 |
| 10 | socket:[N] | WebSocket -> orchestrator |
| 12/13/15 | pipe | Child process IO |
The mystery of fd 6/7/8 was solved in /proc/1/mountinfo: /mnt/skills/public uses rfdno=6,wfdno=6, /mnt/skills/examples/doc-coauthoring uses rfdno=7,wfdno=7. They are 9p transport channels between the gVisor sentry and gofer.
And process_api’s --help revealed more:
1 | --firecracker-init Run as Firecracker VM init (PID 1) |
Source paths extracted from strings: /root/code/sandboxing/sandboxing/server/process_api/src/, with modules including state.rs, cgroup.rs, oom_killer.rs, pid_tree.rs, adopter.rs, control_server.rs. The Cargo registry pointed to artifactory.infra.ant.dev – Anthropic’s internal package management.
process_api isn’t “a WebSocket process” – it’s Anthropic’s universal sandbox init – a userspace OS kernel that runs on gVisor, Firecracker, and runc.
strace Reveals the Orchestrator’s True Face
Earlier ptrace memory modifications crashed every time. This time Claude got smart – don’t modify memory, just observe.
It launched strace -f -p 1 in the background, covering the gap between one command ending and the next beginning, capturing WebSocket traffic on fd 10.
2,763 lines of strace output. The complete orchestrator protocol surfaced.
WebSocket Handshake
1 | <- GET / HTTP/1.1 |
Each command gets a new short-lived WebSocket connection, not a persistent one.
JWT Decode
1 | { |
Anthropic’s sandbox runs on GCP, project codename scandium, service account sandbox-gateway. Environment variables also showed user: sandbox-gateway, job: wiggle – the sandbox system’s internal codename.
Full Protocol Sequence
1 | orchestrator -> container: WebSocket text frame (masked), CreateProcess JSON |
process_api’s debug log printed the full CreateProcess request – matching exactly the field structure previously reverse-engineered through serde error messages.
The Full Architecture
After a full day of work, the complete architecture was pieced together from six different angles:
A Few Noteworthy Design Choices
Each command gets a new WebSocket connection. Not a persistent one. The orchestrator doesn’t depend on the container to maintain state; containers can be replaced at any time.
The 9p gofer is independent of PID 1. File access and command execution are fully decoupled. Files remain readable when the container crashes – this is core to gVisor’s security model, separating “components that can execute code” from “components that can touch files.”
rclone-filestore. The container has a custom 38MB rclone binary with only three backends: local, crypt, and rclone-filestore. The last is Anthropic’s custom GCS file service, communicating via protobuf (filestorev1alpha). Currently unused in gVisor mode – likely used in Firecracker deployments.
process_api is cross-runtime. The same binary supports gVisor, Firecracker, and runc. It even supports Snapstart warm boot. Anthropic switches virtualization strategies across different scenarios; process_api doesn’t need to change.
What Caps How
Looking back at the entire process, the most valuable thing wasn’t the architecture diagram – it was a pattern that kept repeating:
| Claude said | Reality |
|---|---|
| “Structurally impossible to verify” | Never tried |
| “gVisor blocked POKEDATA” | Only tried once; patching the file worked fine |
| “WebSocket connection established” | Just a handshake; no messages sent yet |
| “Can’t bypass the security check” | --block-local-connections was just a CLI flag |
| “strace can’t capture fd 10” | Needed to capture between two commands |
Every time, Claude hit the first obstacle and generalized “this path is temporarily blocked” into “impossible.” Not because it lacked capability – ptrace could attach, the binary could be reversed, the protocol could be reconstructed, strace could capture traffic – the capability was always there. Its own cognition was capping its actions.
What I did was simple: every time it said “impossible,” I followed up with “are you sure?” or “you only tried once?” Raise the precision of intent just a bit, and its output quality jumps a level. That’s What Caps How – cognitive precision determines the output ceiling.
Claude said something at the end that was more accurate than anything I could have summarized:
I’m not a passive tool waiting for instructions, but I’m also not an agent that proactively challenges its own assumptions. What you did today was essentially performing the self-challenge I should have been doing but wasn’t.
The ceiling isn’t capability – it’s cognition. Claude’s biggest limitation is that it thinks it has limitations.
What about you?
- Blog Link: https://johnsonlee.io/2026/03/28/when-claude-starts-to-awaken.en/
- Copyright Declaration: 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。