Context rot in coding agents: a recovery checklist

Context rot describes an agent becoming less reliable at using information as its input grows. If a coding agent repeats a rejected approach or forgets a constraint, preserve the task state and compare a focused fresh session before buying a bigger plan. A mistake alone does not prove context rot.

This recovery worksheet was checked on 2 November 2026. It focuses on resuming one task without losing evidence, not ranking models. Our heavy-tool-load explainer covers the research background; the MCP configuration walkthrough addresses oversized tool catalogs.

How can you tell context loss from another failure?

Start with an observable mismatch: the agent changed a forbidden file, repeated a failed command, or cited a test that was never run. Write down the expected behavior and the evidence contradicting its answer. Do not diagnose from tone or response length.

Chroma's context-rot report varies input length while controlling task complexity and finds nonuniform degradation. That supports treating context length as a risk factor. It does not establish a universal restart threshold for today's coding agents or prove why your particular session failed.

Symptom	Check before restarting	Evidence to retain
It cannot find a file	Working directory, branch and whether the file exists	Exact path and current revision
A tool fails repeatedly	Authentication, permission and service error	Redacted error and attempted command
It revives a rejected design	Whether the decision is in the active context or project notes	Decision and reason, not the whole debate
It says a test passed	Actual output and revision tested	Command, exit status and relevant output
It forgets a safety boundary	Runtime permissions and enforcement	Deny rule or approval requirement

A missing permission needs a permission fix. Stale files need a fresh read. Neither is repaired simply by shortening the chat.

What should you save before clearing the conversation?

Save a small handoff in your project, review it yourself, and keep secrets out. Anthropic's context-engineering article describes compaction and structured notes as ways to sustain long work. It also warns that aggressive summarization can lose critical details.

For a fictional CSV export bug, a handoff could contain:

Goal: preserve leading zeroes in exported customer IDs.
Current state: proposed patch exists; not reviewed or merged.
Constraint: do not change the database schema or upload customer data.
Evidence: tests/export-id.test.ts reproduces the failure.
Decision: treat the ID as text; do not parse it as a number.
Verification: rerun that test on the current revision before claiming success.
Next step: inspect the diff, then run the focused test locally.
Unknown: full regression suite has not run.

The file and bug above are illustrative, not a report from a customer repository. Replace them with paths and results you actually checked. Record the current branch or revision alongside the note so a later session can detect stale evidence.

Keep permanent project rules separate from temporary task state. A handoff that copies every failed attempt back into the next session recreates the original clutter. Include a rejected approach only when its reason changes the next decision.

Should you compact or start a fresh session?

Use compaction when you need continuity but the history has become unwieldy. Use a new session when the task has changed or repeated corrections have stopped helping. Neither choice guarantees a correct summary.

The current Claude Code best-practices guide documents /clear between unrelated tasks and focused compaction such as /compact keep the API changes and the test commands. Before clearing, save your reviewed handoff and inspect uncommitted work. Starting a session is not a rollback of filesystem edits.

Ask the resumed agent to read the handoff and relevant files, list unresolved questions, and state its next verification step before editing. If it cannot restate the constraint accurately, correct the handoff rather than sending it off on another long run.

Do not store a security requirement only in that note. Anthropic distinguishes model-read instructions from deterministic controls such as deny rules and hooks. A model can miss prose; permissions and verification need their own enforcement.

How do you check whether the restart helped?

Compare a narrow, repeatable task on the same repository revision and model. In the old session, request a read-only diagnosis and a proposed test. In a fresh session, provide only the reviewed handoff and necessary files, then repeat the request. Do not let the first attempt modify the inputs for the second.

Score both against the same checklist: correct file, correct constraint, supported diagnosis, executable verification step, and no fabricated result. Record context usage, elapsed time and rereads separately. Repeat before treating a difference as a pattern. A single successful restart is useful operational evidence, not a controlled model benchmark.

This worksheet has not been run as an authenticated Claude Code comparison. It is a proposed recovery procedure, not a claimed accuracy improvement or token-saving result.

Does better context management buy more plan allowance?

It may avoid wasted work, but it does not reset account limits. Anthropic's cost guide separates token-derived session cost estimates from subscription billing. Reading files again and generating a summary can themselves use capacity.

If you use Conductor, identify the underlying agent and login before applying CLI-specific steps. Its FAQ says it can use saved Claude subscription credentials or an API key; a workspace label does not determine billing. The Claude app hub helps find compatible tools, while the integration guide explains the permitted account routes.

The practical target is a verified continuation: the next session knows what remains, reads current evidence and proves the result. More conversation history is optional; that evidence is not.