If you use Claude Code seriously, the official docs get you to competence quickly, but not quite to mastery. That gap is what makes the tool interesting. On paper, it is a terminal-first coding assistant with settings files, approval controls, hooks, subagents, and a handful of CLI entry points. In practice, expert users have found that the public source exposes a broader, more composable surface than the polished documentation admits. The important caveat is simple: those discoveries are a snapshot, not a contract.
The best way to think about Claude Code is as two layers. The first is the documented layer from Anthropic, which is stable enough to build habits around. The second is the source-discovered layer, where undocumented hook fields and behaviours can unlock more ambitious workflows, provided you accept the risk that a future version may change them without ceremony.
Claude Code’s real centre of gravity is configuration
A lot of tools claim to be configurable when they really mean themeable. Claude Code is not in that category. Its settings are split across user-level ~/.claude/settings.json, project-level .claude/settings.json, and an untracked local override at .claude/settings.local.json. That structure matters because it gives you a clean way to separate personal defaults, team conventions, and machine-specific exceptions without turning every repository into a mess of bespoke prompts and shell glue.
For an expert user, this is where Claude Code starts to feel less like a chatbot in a terminal and more like a programmable environment. You can keep personal preferences global, pin project rules close to the codebase, and reserve the local settings file for sensitive or temporary adjustments that should never leak into version control. That layered model is not exotic, but it is one of the clearest signs that Claude Code was built for repeat use rather than one-off novelty.
The clever part is not that Claude Code has settings. It is that the settings layout matches how real teams actually work.
Hooks are where the official product ends and the expert game begins
The official hook system is already substantial. Claude Code supports event-driven automation through SessionStart, UserPromptSubmit, PreToolUse, and PostToolUse. Hooks can return structured JSON that affects continuation and messaging, which means they are not just passive logging points. They can shape behaviour. Even without anything undocumented, that gives advanced users a serious control plane for policy, guardrails, and context injection.
This is also the point where source inspection becomes genuinely useful. The reporting around Claude Code’s public source argues that the runtime accepts undocumented fields including updatedInput, permissionDecision, additionalContext, once, async, and asyncRewake. If those behaviours hold in your installed version, they open up more than convenience. They suggest command rewriting before execution, selective auto-approval paths, and background enforcement patterns that go well beyond the tidy examples in the docs.
That does not mean you should build your workflow on undocumented behaviour and hope for the best. It means you should separate stable automation from opportunistic automation. Use documented hooks for anything you need to keep working. Use source-discovered fields when the payoff is high enough to justify version pinning, testing, and the occasional repair job.
Undocumented does not mean imaginary. It means you are now responsible for the maintenance burden.
Subagents turn Claude Code from one assistant into a small system
Another underappreciated feature is the subagent model. Claude Code subagents are Markdown files with YAML frontmatter, stored in .claude/agents/ for project scope or ~/.claude/agents/ for user scope. They run with their own context and tool permissions. That is a stronger isolation model than most people expect when they first hear the word agent.
In practical terms, subagents let you stop forcing one assistant persona to do everything badly. You can define a reviewer that has tighter tool permissions, a repo-specific migration helper that knows your conventions, or a documentation-focused agent that stays away from risky edit paths. The value here is not theatre. It is separation of concerns. Once you start treating agent files as operational assets rather than cute prompt wrappers, Claude Code becomes easier to reason about and safer to extend.
There is also a subtle cultural shift in this design. Anthropic has made it possible to store these agent definitions as plain files in predictable places. That invites the sort of team discipline developers already know how to apply: review the file, check the frontmatter, discuss the permissions, and keep the useful parts under version control.
Status lines and CLI flows reveal the tool’s terminal-first mindset
Some of the strongest evidence that Claude Code was designed for people who live in shells all day is not in the flashier features. It is in the quality of the command-line ergonomics. The CLI supports the interactive claude session, one-shot prompts with claude -p, continue flows with claude -c, resume flows with claude -r, and update commands. That is not a huge command surface, but it is enough to cover the rhythms that matter: exploratory work, single-task execution, and returning to prior context without pretending every session starts fresh.
The status line feature fits the same pattern. Through statusLine in settings, you can wire in a script that receives JSON context including the active model, current directory, project directory, and cost data. That may sound cosmetic until you have spent a week running multi-step coding sessions and want a constant, low-friction reminder of where you are, what model is live, and how expensive the detour is becoming. Good terminal tools respect glanceability. Claude Code does.
When a coding assistant exposes cost and workspace context in the status line, it is telling you to operate it like tooling, not magic.
The permission model is conservative by design, and that is a strength
Claude Code is permission-gated by default for edits and command execution. Anthropic’s security documentation is explicit about that approval behaviour. For some users, especially those coming from looser agent demos, this can feel obstructive. It is not. It is one of the reasons the tool is credible in real development environments.
The more programmable a system becomes, the more its safety defaults matter. That is especially true once you combine hooks, subagents, and repository-specific settings. A permissive default would make every clever automation trick more dangerous. A conservative default means you can increase autonomy deliberately, case by case, instead of discovering after the fact that your helper quietly acquired the power to rewrite files and run commands in places it should not.
This is also why the undocumented hook surface should be approached with discipline. If you are experimenting with fields such as permissionDecision, you are stepping closer to the part of the system where convenience and risk start to trade places. Expert use is not just about knowing what is possible. It is about knowing what should remain gated.
What expert users should actually take from all this
The missing manual for Claude Code is not a secret list of hidden switches. It is a way of reading the tool honestly. Start with the official docs because that is where the durable behaviour lives: layered settings files, hook events, subagents, status line customisation, core CLI flows, and approval-first security. Then, if you need more, inspect source-based reporting with the right level of scepticism. Treat undocumented capabilities as version-specific evidence, not stable product promises.
That mindset is what separates productive power use from fragile cleverness. Claude Code appears simple because the interface is simple. Underneath, it has the shape of a system you can compose, constrain, and specialise. The docs show you how to use it. The source, at least in some versions, shows you how far it can be pushed. The missing manual lives in the tension between those two facts.