You Don't Need settings.json Hacks to Fix Claude Code

A tweet went viral last week. Over a thousand bookmarks. The claim: Claude Code got "nerfed," and four environment variables in settings.json fix it.

The settings look like this:

{
  "effortLevel": "high",
  "env": {
    "CLAUDE_CODE_DISABLE_1M_CONTEXT": "1",
    "CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": "1",
    "CLAUDE_CODE_DISABLE_AUTO_MEMORY": "1",
    "CLAUDE_CODE_SUBAGENT_MODEL": "sonnet"
  }
}

Here's the deal: these settings aren't wrong. They do make behavior more consistent. But they're a band-aid, not a fix. They trade flexibility for predictability by disabling features you actually want.

The real problem isn't that Claude Code is nerfed. It's that without clear instructions, Claude Code is guessing. And guessing produces inconsistent results.

What Those Settings Actually Do

effortLevel: "high" forces extended thinking on every turn. Claude will reason deeply about everything, including tasks that don't need it. You get consistency, but you also burn more tokens on simple git commits and file reads.

CLAUDE_CODE_DISABLE_1M_CONTEXT turns off the extended context window. The theory: a smaller window forces more focused output. The trade-off: you hit context compression sooner on long sessions, losing earlier context when you need it most.

CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING stops Claude from dynamically adjusting reasoning depth per turn. Every response gets the same thinking budget. Simple question? Same budget. Complex architecture decision? Same budget. Consistent, but wasteful.

CLAUDE_CODE_DISABLE_AUTO_MEMORY kills automatic memory between sessions. No corrections remembered, no preferences carried forward. Every session starts from zero again.

See the pattern? Each setting disables intelligence to gain predictability. That's a losing trade when there's a better option.

The Real Fix: Reduce Ambiguity, Not Features

The best comment in that viral thread wasn't from the original poster. It was this:

"Stability usually comes from less ambiguity, not more tokens."

That's the whole insight. Claude Code isn't inconsistent because its features are broken. It's inconsistent because it doesn't know what you want. Tell it clearly, and the "nerfed" feeling disappears.

This is what a CLAUDE.md file does. It removes ambiguity at the instruction level instead of removing capability at the settings level.

Five Layers of Governance

After running Claude Code daily for months across multiple projects, I've landed on a five-layer system that makes behavior rock-solid without disabling anything.

Layer 1: Global Rules

These apply to every project. They live in ~/.claude/rules/common/ and set your baseline engineering standards.

• Code quality: immutability, file size limits, TDD mandatory, security checks
• Workflow: research, plan, test, review, commit. In that order. Every time.
• Verification: "evidence before claims." Run the proof command, read the output, state the claim with evidence. No "this should work."
• Model routing: use Sonnet for routine work, Opus for architecture. Don't burn expensive tokens on git commits.
• Debugging: systematic three-phase process. Hard stop after two failed hypotheses.

Layer 2: Project Rules

These live in your project directory and specialize the global rules for your specific codebase.

• Standard patterns (fail fast, trust the system, minimal output)
• Git workflow (one branch per epic, humans resolve conflicts)
• Path standards (relative paths only in public-facing output)
• Testing rules (use the test runner agent, no mocking, always clean up)

Layer 3: CLAUDE.md (The Orchestrator)

This is the glue layer. It controls what gets loaded and when:

• Session startup sequence (scan memory index, load relevant shards, check recent handoffs)
• Token budget rules (max 2 files in main thread before delegating to a subagent)
• File placement (screenshots go here, experiments go there, PM docs go somewhere else)
• Boundary rules (nested repos stay independent, runtime state stays out of git)

Read the full CLAUDE.md guide for setup details.

Layer 4: Memory System (Persistent Behavioral State)

This is where corrections become permanent. When you tell Claude Code "don't do X," that correction gets saved to a memory file. Next session reads it. The mistake never repeats.

This is the opposite of disabling auto-memory. Instead of killing the feature, you're making it structured and intentional. A sharded index keeps it lightweight: one-line pointers in the index file, full content in separate shards loaded only when relevant.

Learn how to set this up in the memory system guide.

Layer 5: Session Context (Ephemeral)

Plans, tasks, and conversation state for the current session. Disposable by default. Anything worth keeping gets promoted to Layer 4.

The Anti-Bloat Pattern

The biggest risk with governance files is bloating your context. Every token spent on instructions is a token not spent on your actual work.

The solution: pointer in the index, content in the doc.

Your memory index file (always loaded) contains one-line pointers, not full content. Each pointer links to a shard file that's only loaded when relevant. A fresh session scanning the index sees what exists but doesn't pay the token cost unless it's actually working on that topic.

Same pattern for your CLAUDE.md. Keep it lean (under 100 lines). Link out to detailed docs. The orchestrator stays lightweight while the full governance system stays accessible.

This is the opposite of what most people do. They stuff everything into one CLAUDE.md, wonder why context gets expensive, and then disable features to compensate. Don't do that. Structure it instead.

Settings.json Hacks vs. Governance: A Comparison

Here's what each approach gives you:

The settings.json approach (4 env vars):

• Consistent reasoning depth (but wasteful on simple tasks)
• Predictable context window (but shorter sessions)
• No adaptive behavior (stable but rigid)
• No memory between sessions (predictable but amnesiac)

The governance approach (structured rules + memory):

• Appropriate reasoning depth per task (model routing)
• Full context window with smart token management (subagent strategy)
• Clear instructions eliminate guessing (ambiguity removed, not features)
• Persistent corrections that compound over time (feedback loops)

The settings approach caps out fast. It works for week one. Governance compounds. It gets better every session as your memory system accumulates corrections and your rules cover more edge cases.

Getting Started

You don't need all five layers on day one. Start with two things:

1. A CLAUDE.md file. Run claude /init in your project. Add your stack, conventions, and preferences. Takes 5 minutes. Full guide here.
2. A memory directory. Create memory/ in your project. Add "read memory at session start, write corrections to memory" in your CLAUDE.md. Takes 2 minutes. Full guide here.

That's the 80/20. Seven minutes of setup replaces four environment variables and gives you something that actually improves over time.

Don't disable the intelligence. Direct it.