For about five weeks in early 2026, Claude Code shipped with its default reasoning effort quietly lowered, and developers noticed before Anthropic explained. An AMD executive analyzed 6,852 of his own sessions and measured a 67% drop in model reasoning. The episode left behind a pile of configuration folklore, and most of it is now stale or subtly wrong.
The Claude Code settings genuinely worth your attention in 2026 are four: effort level, permission rules, filesystem hooks, and MCP hygiene. Everything in this post is checked against Anthropic's official documentation and their April 23 postmortem, with links, so you can verify it yourself.
What actually happened to Claude Code in early 2026?
Claude Code did get measurably worse for a stretch, and Anthropic documented exactly why. On March 4, 2026, they changed the default reasoning effort from high to medium on Sonnet 4.6 and Opus 4.6, because some users on high effort saw thinking times long enough to make the UI look frozen.
After sustained community pushback, Anthropic called it the wrong tradeoff, reverted the default on April 7, and published a postmortem on April 23 covering this and two other regressions from the same period. The issue was acknowledged and fixed within weeks, while tutorials teaching people to fight it kept being published for months.
The advice ecosystem around AI tooling moves slower than the tooling itself, which means a well-written tutorial from ten weeks ago can confidently tell you to fight a problem that no longer exists, using a variable that never existed. I spent two decades reading changelogs before trusting tutorials, and this cycle has made that habit mandatory again.
Always check the documentation. Then start configuring the system.
How do you actually control effort level?
There are three legitimate ways to set reasoning effort, and none of them is the CLAUDE_CODE_DEFAULT_EFFORT export you may have seen circulating. Inside a session, type /effort and pick a level. To persist it, add "effortLevel" to your settings.json, or export the environment variable that actually exists:
export CLAUDE_CODE_EFFORT_LEVEL=high
Per Anthropic's environment variables reference, CLAUDE_CODE_EFFORT_LEVEL overrides whatever you set with /effort, so treat the export as a global default and the slash command as the exception for one session.
Is forcing high still worth it? Since the April revert, current models default to sensible effort levels out of the box, so the "always force high" ritual mostly burns tokens on tasks that never needed it. The docs recommend matching effort to the task: low or medium for scoped edits and quick lookups, high for real multi-step coding work. On usage-based billing, high effort can generate several times the tokens of a lower level on the same prompt, because the model reads more files and runs more verification passes before answering.
The same staleness applies to CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING. The variable is real and documented, but it only affects Opus 4.6 and Sonnet 4.6, where it falls back to a fixed budget via MAX_THINKING_TOKENS. From Claude Code v2.1.111 onward, it does not affect newer models, which always use adaptive reasoning.
Which permission settings are worth changing?
Permissions are the settings I would fix before touching anything else, because they solve both of the real daily problems: approval fatigue and Claude reading things it should never read. The default installation asks before most tool calls. On a repository you trust, switch the default mode and hardcode your boundaries in settings.json:
{
"permissions": {
"defaultMode": "acceptEdits",
"allow": ["Bash(git status)", "Bash(npm run *)"],
"deny": ["Read(**/.env*)", "Read(**/.ssh/**)", "Bash(sudo *)"]
}
}
With acceptEdits, file edits and common filesystem commands in the working directory are auto-approved while other tools still ask. For an unfamiliar codebase, plan mode lets Claude read and explore without editing anything. The deny rules are the part people skip, and they are the part that matters. An agent with shell access and no explicit boundaries will eventually read your .env file for a perfectly logical reason. I wrote about this failure mode at length in when your AI agent has the keys to everything, and the short version is that access control belongs in configuration, not in prompts.
This is the same lesson I applied at Green Hat, long before agents. Across 30+ client projects, developers had full access to dev, limited access to staging, and zero access to production, with every production deploy going through a PR I approved. Nobody debated permissions in the moment because the boundaries were set in advance.
Agents deserve the same treatment humans got. Set the rules once, in a file, where they cannot be talked out of.
Do hooks replace manual formatting?
Yes, and hooks are where most tutorials point in the right direction with the wrong syntax. A common broken example uses a matcher like "Write(*.ts)", which is not how matchers work. Per the official hooks guide, the matcher targets tool names (as a regex like Edit|Write), and your command reads the tool input as JSON from stdin to get the file path:
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
}
]
}
]
}
}
That single hook removes the entire category of "Claude wrote the file, now I run the formatter" busywork. A PreToolUse hook on Bash can do the inverse job as a guard: inspect the command about to run and exit with code 2 to block it. If you copy the broken matcher syntax instead, the hook simply never fires, and you will spend an afternoon wondering why.
For the WordPress side of my work, the same pattern runs phpcs against edited plugin files, which is how I keep Claude Code inside WordPress workflows without letting coding standards drift.
Is MCP token overhead still a problem?
The previous overhead was genuinely bad: Anthropic's own engineering write-up measured a five-server setup consuming roughly 55,000 tokens in tool definitions before the conversation even started, with a single heavy server like Jira eating about 17,000 on its own. Those figures fueled a wave of "disconnect everything" advice.
Then Anthropic shipped MCP tool search, enabled by default, which withholds tool definitions from context and loads only what Claude needs per turn, cutting the overhead by around 85%. Disconnecting servers you have not touched in weeks is still worth doing, if only because fewer similarly-named tools means fewer wrong tool selections. But it moved from emergency triage to routine hygiene, and any article quoting a fixed per-server token cost is describing the world before tool search existed.
The takeaway
If you configure only four things, make them these: set effortLevel deliberately instead of leaving it to folklore, define allow and deny permission rules with .env and .ssh explicitly denied, add one PostToolUse formatting hook with the correct matcher syntax, and prune MCP servers you no longer use. Skip anything that promises to reverse a nerf, and check the date on the postmortem before you check the date on the tutorial.
The deeper habit is treating your agent's configuration the way you treat production infrastructure. Versioned and reviewed like any other code, with claims checked against primary sources instead of tutorials, because the tooling now changes faster than the content written about it. My Claude Code setup guide for macOS covers the baseline install this post builds on, and PACREF covers the prompting side once the environment is sane.
Your environment is either engineered or inherited from a random tutorial. Which one is yours?
If your team adopted Claude Code six months ago and nobody has audited the settings, permissions, or hooks since, that review is exactly the kind of consulting I do. Get in touch.