Claude Code /doctor: the health check became a context audit
6m read time verified against Claude Code 2.1.203

Claude Code /doctor: the health check became a context audit

What /doctor actually checks in Claude Code now: ten checks, and only two of them care whether the thing is installed. The rest audit what you loaded.

Run claude doctor from your shell and you get a tidy little report. Version, install method, platform, auto-update channel. Mine ends with "No installation issues found." Twelve lines, all green, nothing to do.

Then run /doctor inside a session and you get ten checks. Two of them ask whether Claude Code is installed and current. The other eight ask what you did to it.

That gap is the interesting part. The command kept its name and quietly changed its job.

What /doctor actually checks now

/doctor (alias /checkup) stopped being a CLI subcommand and became a bundled skill in 2.1.203. It reads your settings, your skills, your MCP servers, your plugins, your hooks and your memory files, then proposes changes. Here is the full list, straight from the skill:

#Check
0Setup health: installation, settings, agent definitions
1Unused skills, MCP servers and plugins
2Local CLAUDE.md dedup and contradictions
3Trim derivable content from checked-in CLAUDE.md files
4Migrate always-loaded CLAUDE.md content to lazy loading
5Slow hooks
6Context-heavy extensions
7Claude Code version
8Auto mode as the default permission mode
9Pre-approve frequently denied read-only commands

Checks 0 and 7 are the old health check. Checks 1 through 6 are a context audit. Checks 8 and 9 are something else again, and I'll come back to those.

The accounting in check 6 is specific enough to be useful: it estimates always-resident context per component, breaks out each memory file, and measures your skill and command listing against a budget of roughly 1% of the window. It also tells you its numbers are disk-based estimates and points you at /context for the live measurement, which is a level of honesty I did not expect from a tool selling you its own cleanup.

Why this arrived now

Sonnet 5 shipped with a 1M-token window on 30 June. Opus 5 followed on 24 July with the same. Both are the default in Claude Code for their tier.

Back when the window was 200k, setup rot announced itself. You loaded eleven plugins and a 400-line CLAUDE.md, and by mid-afternoon you were watching the compaction warning and cursing. The wall was annoying, and the wall was also feedback.

At a million tokens almost nobody hits the wall. The rot is still there, it just stopped erroring. Your agent gets a little vaguer, a little slower to start, a little more likely to follow the stale instruction three sessions after it stopped being true. Nothing in the interface tells you, because nothing broke.

So Anthropic shipped a linter for it. That is what checks 1 through 6 are: a linter for the mess that no longer has a symptom. I've argued before that a plugin stack can cost more context than it saves, and this is the vendor conceding the point by building the meter.

The check that edits your memory

Check 3 is the one worth slowing down for. It proposes trimming your checked-in CLAUDE.md by cutting content Claude could derive from the codebase. Directory layouts, dependency lists, architecture overviews: gone, because the agent can read all of that. Pitfalls, rationale and conventions that differ from tool defaults: kept.

The dividing line is exactly right. I've argued the same thing about stale memory, where the file that describes your folder structure is the file that lies to you six weeks later.

What makes me sit up is who draws the line. "Content Claude could derive from the codebase" is the model assessing its own inference, and self-assessment is the one capability these things reliably lack.

It will confidently propose cutting the line that looked redundant and was actually load-bearing, the one that stops it doing the thing it does every single time on this repo. The proposal will read perfectly reasonable. You will not remember why that line was added, because you added it eight months ago after the third incident.

/doctor reports findings first and asks before it changes anything, so you get a diff. Read it like a pull request from a fast, eager junior who has never seen this repo before, which is precisely what it is. The rule about never shipping code you don't understand covers your memory file too. That file is configuration, and configuration outranks code for blast radius per line.

Checks 8 and 9 have an opinion

Check 8 proposes making auto mode your default permission mode, user scope, every project. Check 9 finds read-only commands you keep denying and offers to pre-approve them.

Both are defensible. Check 9 is straightforwardly good: if you've said no to git status forty times, the prompt is furniture. And the skill is careful about check 8, skipping when policy or project settings pin a different mode, noting that the CLI falls back safely if auto mode is unavailable.

Still, notice what happened. A tool called "doctor" now recommends a looser default permission posture as part of a health check. That framing does work, because nobody argues with a diagnostic. If you want auto mode, take it deliberately, with the permission model in your head, and not because a green checklist offered it between a hook timing report and a version bump.

The bit that surprised me

Buried in check 1 is an instruction the skill gives itself: never report a token cost for deferred MCP tools, and never recommend disabling an MCP server to save context when its tools are deferred.

MCP tool schemas now sit behind a search tool by default. Only the name is resident, the schema is fetched on demand. So the standard advice, prune your MCP servers because they eat your window, is mostly obsolete.

The skill knows this and refuses to take credit for savings that would not happen. It still suggests removing servers you never invoke, framed honestly as one less thing to authenticate and maintain.

A cleanup tool that declines to overstate what its cleanup buys you is a good sign about the rest of it.

How I run it

claude doctor from the shell is read-only. Run it whenever something feels off about the install itself.

Neither command looks at the session you are sitting in right now. That has its own meter and its own habits, and it rots on a timescale of hours rather than months.

/doctor in a session is an agent with edit rights on your configuration. I run it roughly monthly, at the start of a session where I still have the patience to read a diff. At the end of a long day the checklist is the last thing between me and a merge, and I would wave the whole thing through.

Accept without much thought: version bumps, slow hook reports, dedup of local memory files against checked-in ones, servers you have genuinely never called. Read line by line: anything touching a checked-in CLAUDE.md, and both permission proposals.

The command that used to tell you the tool was broken now mostly tells you that you are. Ten checks, and eight of them are about decisions you made. That is a worse report to receive and a far more useful one.

(25 of 35)
01Getting the best out of Claude Code02Superpowers: teaching Claude Code to think before it types03Claude Code hooks: deterministic control over AI workflows04The CLAUDE.md file: give your AI permanent memory05Stop asking your agent nicely06What's new in Claude Code: notes from the London talk07The best number in Opus 4.8 isn't a benchmark08Stale memory is worse than no memory09The agent is just a loop10Build an MCP server, then ask whether it should exist11Skill, subagent, hook, or slash command? Pick the right one12Log in to MCP servers from your shell13How to give Claude safe access to your SQL database14The day 'default' became 'Manual'15How to write a proper Claude Code skill16How to write a proper Claude Code subagent17Claude Code permissions: the guide I wish the docs were18Sandboxing Claude Code: put your agent in a box that holds19Prompt injection defense for developers who ship agents20Which Claude model for which coding task21Refactoring legacy code with a coding agent: start with characterization tests22MCP server authentication: OAuth, scopes and rate limits23Opus 5 is here and your effort settings just expired24AI agent incident response: what to do when your coding agent goes wrong25Claude Code /doctor: the health check became a context audit26Claude Code context management: when to /clear and when to /compact27Git worktrees for parallel coding agents: what they isolate and what they share28Claude Code plan mode: decide before the agent writes29Debugging with a coding agent: give it the search, keep the hypothesis30Claude Code checkpoints and /rewind: how to undo an agent's changes31Claude Code cross-session messaging: how to make your sessions talk to each other32Audit logging for AI agents: what Claude Code records and what deserves a human33Sharing Claude Code config across a team: what a repo can and cannot enforce34Your Claude Code session has no clock35Claude Code in a large codebase: scoping an agent to the part that matters