A developer who sat down to read through Claude Code's source code recently published their findings, and it struck a nerve with the dev community. The write-up landed on Hacker News' front page with hundreds of points, sparking exactly the debate every "I read the source" post inevitably does: half the audience cheered, the other half reminded everyone that "undocumented" and "you should use this in production" are not synonyms.
The Config Layers Nobody Explores
Most developers configure Claude Code at the surface level—a CLAUDE.md file with project instructions, maybe a permission allowlist so it stops asking before every npm command, and whatever model is selected. That covers maybe 10% of what's actually available. The official settings documentation goes considerably deeper, but it's scattered across multiple pages in ways that make the pieces hard to connect. Environment variables are a prime example: everything you can set on the command line can live in settings.json under an "env" key instead. This means your whole team can share configuration by committing it to .claude/settings.json rather than asking everyone to export variables in their shell profile. That's documented, but you'll search for it a while before finding it.
Why Your Teammate's Claude Code Behaves Differently
Permissions are the other underutilized piece of this puzzle, and understanding them explains a common source of confusion: permissions merge across scopes rather than override. User-level rules, project rules, and managed settings all stack together. If you've ever "removed" a permission rule and found it still applying, check your other config files—it was probably set somewhere else in the hierarchy. This is why two developers working on the same repository can have meaningfully different experiences with Claude Code without either of them realizing their settings don't match.
Hooks: Where the Real Power Lives
The hooks system separates people who treat Claude Code as a fancy chat interface from those who've turned it into a build system component. Three hook types exist, and most developers only know about one. A command hook runs a shell command at lifecycle points—before a tool executes, after an edit, when a session starts, or while Claude waits for input. A prompt hook sends a single-turn question to the model and receives back a yes/no decision in JSON format, which is perfect for judgment calls that can't be resolved with simple pattern matching. An agent hook spawns a subagent capable of reading files via Grep and Glob before rendering its verdict. That progression from regex-based rules to quick model calls to full agents represents substantial capability most users never discover exists in the official documentation.
What the Source Dive Gets Right (and What It Doesn't)
The reverse-engineering analysis goes further, claiming hooks can return richer JSON to steer behavior mid-execution—forcing allow or deny decisions, injecting context, even rewriting commands before they run. Some of this aligns with documented functionality. Other elements, like background async hooks or a "once" flag that fires a hook a single time and self-removes, represent the author's interpretation of internal fields rather than confirmed API behavior. Internal field names change between releases without announcement, and a hook that silently stops firing is worse than no hook at all. Treat undocumented discoveries as leads to verify against official docs before building anything critical around them.
The Security Piece Nobody Should Skip
HTTP hooks can interpolate environment variables into request headers, which enables powerful integrations—but also real risk if you're connecting to services that use secrets. Settings now include the ability to restrict which variable names a hook is allowed to read. If you're wiring Claude Code into any system that touches actual credentials, that allowlist isn't optional. It's the difference between a hook that sends an auth token to one specific endpoint and one that can access your entire environment.
The Bottom Line
Claude Code is more configurable than its documentation suggests, but the real value sits in features that are documented—just buried rather than missing entirely. Before diving into reverse-engineered internals, audit how your permissions actually merge across scopes, move shared configuration into committed settings files for your team, and consider whether a prompt hook could replace a brittle regex rule. The gap between what Claude Code's marketing suggests it is ("it writes code") and what it actually is (a configurable runtime with permissions models, lifecycle hooks, and multi-scope settings merging) contains most of the value worth extracting. Read the official references first. Save the source-diving for when you've outgrown them.