Context Rot in Claude Code: How to Spot It and Reset Cleanly

A long Claude Code session feels productive. Claude has read half the codebase, knows every decision, and you do not want to lose any of it. In practice, that same session is often where the quality quietly drops. Instructions from an hour ago get ignored, fixed bugs come back, and answers get vaguer. That is context rot, and once you know how to spot it, it is easy to manage.

What context rot actually is

Everything in a session lives in one context window: your messages, Claude's replies, every file it read, every command output. Anthropic's article on context engineering describes context rot as the model's ability to recall information getting worse as the number of tokens in the window grows. The Claude Code docs put it plainly: performance degrades as the context fills, and Claude may start forgetting earlier instructions or making more mistakes.

So a bigger context window is not a cure. It gives you more room, but the old exploration, the failed attempts and the stale logs are still in there competing for attention.

The signs your session is rotting

• Claude breaks a rule it followed perfectly at the start.
• It reintroduces a bug you already fixed together.
• It refers to a file or function name that changed an hour ago.
• You have corrected the same thing twice and it is still wrong.
• Answers get longer and less specific.

When I see two of these, I stop pushing and reset. Arguing with a rotting session almost never works. A clean session with a better prompt does.

Check what is in the window

Run /context. You get a grid of everything loaded: system prompt, tools, memory files, skills and the conversation itself, with suggestions when something is oversized. If most of the window is conversation, you have a rot problem. If most of it loads before you type anything, your setup is the problem, and the fix is a shorter CLAUDE.md and fewer always on tools.

Pick the right reset

Claude Code gives you several ways to shrink context. Each fits a different moment.

• /clear when you switch to unrelated work, or after two failed corrections. Full wipe, no summary, and it costs nothing.
• /compact with a focus when the task continues but the thread is long. You decide what the summary keeps.
• Summarize part of the conversation when only one stretch is noisy. Press Esc twice or run /rewind, pick a message, and choose Summarize from here or Summarize up to here.
• /btw for side questions. The answer never enters the conversation history, so checking a detail does not grow the session.

A focused compact looks like this:

/compact Keep the goal and definition of done, decisions made and why, every file we changed, unresolved errors, commands and tests we ran with results, and the exact next step. Drop the exploration.

Write a handoff before a hard reset

When I clear a session in the middle of a larger piece of work, I ask Claude to write the handoff to a file first. A file survives anything. A summary in chat does not.

Write HANDOFF.md in the project root with: the goal, what is done, decisions and the reason for each, files changed, open problems, and the next three steps. Keep it under 40 lines. Do not include anything I can read from git log.

Then run /clear and start the new session with one line: "Read HANDOFF.md and continue from the next step." You get a fresh window with only what matters in it.

Know what survives compaction

Compaction replaces the conversation with a structured summary. Some things come back on their own and some do not, so it helps to know the difference.

• Reloaded from disk: your project root CLAUDE.md and unscoped rules, auto memory, and the plan Claude wrote in plan mode.
• Partly restored: up to five of the most recently modified files are read again, and skills you invoked are injected again with a size cap, so keep the key instructions near the top of each SKILL.md.
• Gone: anything you only said in chat, full tool outputs and intermediate reasoning.

The practical rule: if an instruction must survive, put it in CLAUDE.md, not in a message. You can also tell compaction what to keep by adding a short section to CLAUDE.md:

# Compact instructions
When compacting, always preserve the list of modified files, the test commands we use, and any unresolved errors.

For dynamic state, a SessionStart hook with the compact matcher runs after every compaction and adds its output to the fresh context. The hooks guide shows the exact setup. A command like git log --oneline -5 is a good start.

Keep heavy reading out of the main session

The biggest source of rot is exploration: reading twenty files to find the three that matter. Hand that to a subagent. It reads in its own context window and returns only the findings.

Use a subagent to find how session timeouts are handled in this codebase. Return only the relevant file paths, the key functions, and open questions. Do not paste file contents.

Your main session stays focused on the actual change, which is where you want Claude's attention.

Compact earlier on long projects

Claude Code compacts on its own when the window is nearly full, but by then the rot has been building for a while. Run /autocompact to see or change how full the window gets before it compacts automatically. Compacting a bit earlier, at a moment you choose, keeps summaries cleaner.

Start small. Next time a session drifts, run /context, ask for a handoff file, and clear. Once that feels natural, add the compact instructions to your CLAUDE.md and move your research into subagents. The context window explorer in the official docs is worth ten minutes if you want to see exactly what loads when.