How Much Claude Code Customization Do You Need

Boris Cherny, the engineer who created Claude Code, published a thread on X walking through his personal setup. He wrote: "My setup might be surprisingly vanilla! Claude Code works great out of the box, so I personally don't customize it much." From the person who built the tool, has access to every internal feature, and dogfoods it daily on one of the most demanding codebases the tool touches, that is useful information. People searching for "what should my Claude Code setup look like" will find a simpler answer from the source than the internet suggests.

Why the creator uses a vanilla setup

There is a whole content economy around agentic coding setups, and it favors elaborate setups. A screenshot of a 400-line CLAUDE.md, a dozen MCP servers, a lattice of hooks, and a directory of custom subagents makes a compelling post. "I mostly use the defaults" does not. The setups that circulate are selected for elaborateness, and a newcomer reasonably concludes that elaborateness is what competent usage looks like.

Cherny's setup shows that heavy customization does not reliably produce better results. He has the fewest constraints on customization: no permission friction, complete knowledge of every extension point, and colleagues who built each subsystem sitting nearby. Instead he reports keeping it close to stock, and he is explicit that this is a personal choice rather than a prescription: "There is no one correct way to use Claude Code: we intentionally build it in a way that you can use it, customize it, and hack it however you like. Each person on the Claude Code team uses it very differently."

The tool is deliberately built as a hackable surface, and the team that builds it has not converged on a single configuration. The setups going viral are one point in a wide distribution, and copying any single one wholesale transplants someone else's workflow constraints onto yours.

Claude Code customization layers

Claude Code exposes several distinct extension layers, each with a different cost profile:

Every layer spends context window, adds latency, or creates an artifact you now maintain against a tool that ships changes constantly.

Customization costs

Context is the clearest example. A long CLAUDE.md is loaded whether or not the current task needs any of it, and every MCP server you attach contributes tool definitions to the window before the model has read a single file. Individually these are small, but ten together create a standing tax on every turn of every session and crowd out the code the model should be reading. A CLAUDE.md line describing a build step that changed three months ago can do more damage than no line at all because the model will confidently follow it.

A hook that runs your formatter after every edit can fight the model on a file the formatter mangles, or add two seconds to every one of the hundreds of edits in a long session. Use hooks for hard guarantees that must hold deterministically. Preferences the model would follow after being asked once do not need hooks.

The default configuration is exercised continuously by the vendor's own team and by an enormous user base, so regressions against stock behavior get found fast. Your bespoke stack of hooks, subagents, and injected instructions is tested by one person. When a new model version or CLI release shifts behavior, stock setups mostly get better. Heavily customized ones can get worse in ways that take an afternoon to diagnose because the interaction between the new model and old scaffolding is a configuration nobody else on earth is running.

Customization priorities

Configuration should follow observed need. A reasonable ordering, from highest return to most situational:

1. A short, operational CLAUDE.md. Keep build and test commands with non-obvious flags, the one directory that must never be synced, and the service that holds code in memory and needs a restart after edits. The model can infer code style and architecture philosophy from the surrounding code.

2. A permissions allowlist. If you approve the same command every session, encode that approval. This removes friction without adding context or behavior.

3. A hook, after the second occurrence of the same failure. Write a hook after a concrete, repeated event you watched happen, and use it to enforce something that must be true one hundred percent of the time. Speculative hooks accumulate mystery latency.

4. An MCP server, when the agent needs a system it cannot reach otherwise. If a plain CLI exists for the service, the agent can usually run it with no standing schema cost. MCP earns its place for systems with no good command-line surface, or where you want the typed tool interface for permission control.

5. Skills and subagents, for workflows you have already run manually several times. These codify proven procedures. Codifying a procedure you have never executed writes documentation for a process that does not exist yet.

Each addition should respond to something that went wrong or dragged twice in real usage. That keeps the setup small because most things never go wrong twice.

What "no one correct way" means for teams

Cherny's line that each person on the Claude Code team uses it very differently also applies to teams adopting the tool. Teams often try to standardize one blessed CLAUDE.md, one hook suite, and one set of MCP servers for everyone. Project-level facts such as commands, gotchas, and invariants belong in checked-in configuration because they are properties of the codebase and everyone benefits from the same ones. Personal ergonomics such as permission tolerances, slash commands, and delegation to subagents belong to the individual because they encode how a particular person likes to work. The team that built the tool has not standardized those.

Cherny runs Claude Code nearly stock. The elaborate setups people are chasing often add maintenance and context costs without adding capability.