Why Claude Code Forgets Earlier Instructions After Context Compaction

Claude Code can forget earlier instructions after context compaction because it continues with a compressed account of the conversation. A requirement mentioned only in chat may lose an exception, a reason, or its original emphasis during summarization. That can leave Claude remembering the general task while missing an important restriction.

However, compaction does not erase every kind of instruction. Claude Code reloads the project-root CLAUDE.md from disk. Instructions stored in nested files or path-specific rules reload when Claude reads the files they apply to. A rule that was present before compaction may therefore need its loading condition to occur again.

What context compaction actually changes

The context window is the information available to the model while it works: messages, instructions, file contents, and tool results. As this grows, Claude Code manages space by clearing older tool output and, when necessary, summarizing the conversation.

A summary must select what matters. Consider a fictional task where you asked Claude to fix a date parser while preserving the public function signature. Later, you clarified that a particular error message must also remain unchanged because another application reads it. A shortened account might retain the parser objective and signature restriction but miss the error-message exception.

That example illustrates a possible failure, not a report of a test. It explains why “Claude remembers the project” and “Claude has every earlier constraint” are different observations. Remembering the main objective does not demonstrate that all its boundaries survived.

For broader background, Ars Technica's explanation of coding agent context discusses how these tools use compression and external notes during extended work.

Which instructions should survive?

How information returns depends on where it was stored. Use this distinction before rewriting your prompts:

An ordinary task note you create is not automatically equivalent to the built-in plan. If you keep decisions in docs/task-notes/parser-fix.md, explicitly ask Claude to read that file when continuing. Naming a document HANDOFF.md does not itself establish a loading rule.

Diagnose the symptom before changing settings

Choose one concrete instruction that was missed. “It forgot everything” is difficult to investigate; “it changed the error message after I prohibited that” gives you something to check.

The timing alone does not prove a compaction bug. During a long session, you may also switch branches, change task scope, edit instruction files, or introduce a conflicting request. Record what changed rather than treating every later mistake as evidence of lost memory.

If the same rule also fails in fresh sessions or another coding tool, the broader guide to project instruction troubleshooting covers discovery, scope, and conflicting guidance across assistants.

Recover the missing instruction without restarting the task

1. Pause edits and inspect the current work

If Claude is still working in the wrong direction, press Esc once to stop it. Then inspect the affected files and changes. In a Git repository, these read-only shell commands provide a starting point:

git status --short
git diff --stat
git diff

The last command shows unstaged changes. If files are staged, also inspect git diff --cached. Read relevant new files separately because untracked file contents do not appear in a normal diff.

Identify which changes belong to this task and which were already present. Avoid a blanket reset merely because Claude ignored a restriction; it could remove your own unfinished work along with the unwanted edit.

If you find unrelated file changes, review the permitted editing scope and any formatting or generation commands that may have rewritten additional files before continuing.

2. Check what instruction files actually loaded

Inside Claude Code, run /context and inspect the Memory files section. Use /memory to open and edit the relevant instruction files. The two commands answer different questions: /memory can list file locations that do not yet exist, so its menu alone does not prove the file is loaded.

If a required file is missing, confirm the working directory and instruction location. For a component-specific rule, ask Claude to read the relevant component file and then check the loaded context again. A loading problem needs a loading fix; making the same unseen instruction more emphatic will not resolve it.

3. Re-establish the task with specific evidence

Correct the missing requirement directly. Include the active goal, permitted scope, important exception, and what remains unverified. This illustrative prompt continues the parser example:

Pause further edits. The active task is to fix the date parser.

Preserve the public function signature and the existing error text.
Do not change the serialization module as part of this task.
The integration check has not run; do not describe it as passed.

Read the applicable project instructions and inspect the current diff.
Identify any changes that conflict with these requirements.
Propose the smallest correction before editing.

Replace those details with your actual requirements. Do not copy the example's test status into a real session unless it is true. The purpose is to rebuild an accurate working record, including uncertainty.

If you no longer remember the exact wording, look for the original message, specification, or approved note. Claude Code's /export command can save a readable conversation transcript; passing a filename writes directly to that file. Search the available record for the relevant decision rather than feeding the entire transcript back into context.

An export is a record to inspect, not a command that automatically restores missing instructions. Check that it contains the passage you need. If the original evidence is unavailable, make a fresh explicit decision instead of asking Claude to reconstruct an agreement from guesswork.

4. Check the next action, not just the apology

Ask Claude to state which files it intends to change and how it will verify the result. Compare that plan against the restriction that was missed. A reassuring response is useful only if the proposed work now fits the task.

For the parser example, check the signature and error text in the proposed diff. After the correction, run the relevant regression check. Keep “the instruction was restated,” “the edit respects it,” and “the result was tested” as separate conclusions.

Prevent the same requirement from disappearing again

Keep stable project rules in persistent instructions

Use the project's existing CLAUDE.md for rules that should apply repeatedly. Claude Code supports project instructions at ./CLAUDE.md or ./.claude/CLAUDE.md. Follow the repository's established organization and preserve its existing guidance.

For example, a standing requirement to maintain public API compatibility belongs with project conventions. A temporary restriction to change only two files for today's bug belongs in the current task record. Combining every historical task into permanent instructions makes it harder to tell what still applies.

Write requirements so someone reviewing a diff can check them. “Keep things compatible” leaves room for interpretation. Naming the public interface, expected error behavior, and compatibility check gives the instruction a concrete meaning.

Our guide to structured prompt writing includes ways to separate tasks, constraints, and output requirements. Use that organization to clarify what you need, while still verifying Claude's actual changes.

Keep changing decisions in a short task note

Record the facts that would be expensive to reconstruct: the approved goal, decisions and reasons, files changed, checks actually completed, and the next unresolved step. Update the note at useful milestones and explicitly have Claude read it when work resumes.

In the parser example, a useful entry would explain why the existing error text matters and where its regression check lives. A note saying only “parser discussed” cannot recover that decision. Equally, “tests passed” is inadequate if only a subset ran.

Review notes against the current files. A persistent but stale instruction can cause a different kind of failure: Claude may faithfully follow a decision that you have already replaced.

Give compaction a narrow preservation goal

Before a planned transition, you can guide a manual compaction:

/compact Preserve the active task, scope restrictions, compatibility decisions and their reasons, verification results, and unresolved next step. Condense repeated logs.

For recurring guidance, add a short Compact Instructions section to the project's CLAUDE.md. This sets summary priorities; it does not make summarization lossless. Asking to preserve the entire conversation defeats the purpose of reducing context.

Reduce irrelevant input during long sessions

Anthropic's context-engineering guidance describes reliability problems in long contexts even before information is summarized. More available tokens do not automatically make every instruction easier to follow.

Request targeted file sections and relevant error excerpts instead of repeatedly loading complete logs. Keep unrelated investigations in separate sessions. If you decide to use /clear for a fresh task, save the current decisions first: clearing starts a fresh conversation and does not preserve the active discussion as a compaction summary.

When persistent instructions are still ignored

A loaded CLAUDE.md is guidance expressed in natural language. It is not an enforcement mechanism. If Claude can identify the rule but still violates it, investigate ambiguity, competing instructions, and the specific action it took.

For an operation that must require approval or be blocked, use the appropriate permission controls. A PreToolUse hook can also evaluate a tool call before it runs. These mechanisms need correct scope and configuration; a rule covering one tool or command form is not automatically a boundary around every possible way to perform that operation.

Likewise, a reminder to run tests is different from a test that actually fails a build. Put objectively checkable requirements into the project's normal validation workflow where practical. This gives you evidence of compliance after any context transition.

To investigate a repeatable failure, record the Claude Code version using claude --version, the exact rule, its location, whether it appeared under /context, and the first conflicting action. Reproduce with a small non-sensitive task and keep other variables unchanged. A focused example is more useful than a long transcript containing several unrelated problems.

Frequently asked questions

Does context compaction delete my project files?

Compaction summarizes conversation context; it is not a file-deletion operation. If files changed, inspect the recorded edits and commands. Do not confuse a missing conversational detail with a missing file on disk.

Will auto memory save every earlier instruction?

No. Auto memory stores selected learnings, not a complete copy of every request. Review what was saved through /memory. Keep explicit standing requirements in project instructions and current decisions in a maintained task record.

Does a larger context window prevent forgetting?

A larger window can hold more information, but it does not guarantee reliable use of every detail. It also does not fix an instruction file that never loaded. Diagnose the missed requirement before treating capacity as the solution.

Should I disable automatic compaction?

That is not the first fix for missing instructions. Disabling compaction does not create unlimited context or enforce compliance. Start with persistent rules, focused input, and a check of the next proposed action.

Can I undo changes made after Claude forgot a restriction?

Use Git or an applicable Claude Code checkpoint after inspecting what will be restored. The /rewind menu distinguishes restoring code from restoring conversation. Checkpoints do not cover every change, including ordinary Bash-command file modifications, so confirm coverage and preserve unrelated work before restoring.

Start with the next instruction Claude misses: locate its source, confirm whether it loaded, restate the precise requirement, and inspect the next diff. That gives you a concrete repair and tells you whether the lasting fix belongs in instruction storage, task notes, or enforcement.