The Claude Code Binary Is the Only Documentation That Never Goes Stale
Last night I was reviewing a plan for one of my plugins, and the whole plan hinged on one claim: a startup hook in Claude Code can add context to a session, but it can’t make the session do anything. That was true on the version I’d checked three weeks earlier, it was in Claude’s notes, and I believed it. Then I asked Claude to review the plan against the actual internals, and it came back with a correction. On the build installed that morning, a SessionStart hook can return a field that gets fed into the conversation as if I’d typed it, and the binary itself uses that same path to run a slash command. So a hook can force-load a skill now. The plan changed before a line of it was written, because the thing it hinged on was wrong.
Nothing in the docs would have told me that on the day it mattered. The docs list the field now, so they got there. But the plan was being made that day, and the program sitting on my disk already knew the answer.
The Program on Disk Already Knows
Documentation for a fast-moving tool has three problems and they’re all structural. It lags the release. It leaves things out, partly on purpose, because documenting a field is a promise to keep it. And it describes the version the writer had open, which is never the version you have installed. None of that is a complaint about Anthropic’s docs, which are good. It’s what docs are. The installed binary has none of those problems: it is, by definition, an exact description of what the thing you’re running can do, today.
What changed recently is who can read it. Claude Code ships as one minified JavaScript bundle, about 326MB on the version I have, and for a human that’s a wall: names like vui, $Ia and Ne.bool(), everything on one line. For Claude it’s just text. It reads minified code about as comfortably as it reads prose, follows a one-letter function back to the gate table it came from, and tells you whether the thing that looks like an environment variable is actually a remote feature flag. So the binary didn’t get more readable. The reader got good enough that the source became the better docs.
How I Actually Do It
Most of the time I type a sentence. “Review that against the actual internals of Claude Code.” Claude finds the installed binary, greps it as text, and reports what’s there. That’s it. The few times I wanted to see for myself, it’s the same thing by hand:
grep -aoE ".{0,200}NEEDLE.{0,200}" ~/.local/share/claude/versions/2.1.235The trick is picking needles by shape. The literal string a feature prints. CLAUDE_CODE_[A-Z_]_ for env vars. "key"\s_: for settings keys. And best of all, validator error messages: a string like “hook returned updatedToolOutput that does not match” proves both that the field exists and that it’s checked. One grep with every needle in an alternation, piped through sort | uniq -c, gives you a presence table for the whole file in one pass. It cost about six greps the first time, and that’s the argument: the check is cheaper than being wrong.
The part that makes it compound is what happens after. Findings go into a memory file with the exact version they were mined from, so the next question is a file read instead of another mining pass. And the memory carries its own instruction to re-verify on a version bump, which is how I caught the startup-hook change. It’s a standing rule in that project now, written down after I let an agent’s claim through unverified once. The rule’s wording is the useful bit: any claim of the form “Claude Code can’t do X” gets checked against the binary before it’s acted on, whether it came from the docs, from a subagent, or from Claude’s own training, because all three are hearsay about a program on disk. Negative claims especially. “There’s no way to do X” is the one that quietly caps every solution you’ll consider after it.
A few things that came out of it, as of August 2026. The hook that runs before a context compaction can rewrite the summarizer’s instructions as well as veto the compaction; the docs still don’t mention the field. The one-hour prompt-cache tier is on an allowlist that subagents can never match, so a cost model that assumes one cache rate is wrong for every subagent. There is no way, from a plugin or a setting, to filter the diagnostics block that gets pushed into context, which meant a fix I’d been planning wasn’t possible and the real fix was structural. And the agent-worktree path is a literal in 23 places with nothing overriding it. Three of those four were load-bearing for a ticket, and each took minutes.
Reading Isn’t the Same as Running
The method has limits, and they’re worth knowing. What’s present in the binary isn’t necessarily enabled for your account; feature gates are decided server-side, so a command you can see in the file can still answer “unknown command”. Things that look like env vars sometimes aren’t. Behavior moves between patch versions, and it moves fast: the constant that sets where auto-compaction fires kept its value across eleven days but changed which threshold it belonged to, which is exactly the kind of drift the re-verify rule exists for. And once, the binary read was correct and the behavior still didn’t happen: a hook matcher that the code’s own switch statement says should fire never did, and only a real test settled it. Reading is necessary. It’s not always sufficient.
The docs also catch up, which is fine. The SessionStart fields were undocumented when Claude first found them and documented three weeks later. The binary buys you lead time and precision, and lead time is the whole game when you’re deciding today what to build.
If there’s one habit to take from this: the next time you’re about to design around “Claude Code can’t do that”, ask it to check. The answer is on your disk, it’s one grep away, and it’s the only version of the docs that’s guaranteed to match what you’re running.