Why Claude Code stops following instructions you gave it earlier (it's not being stubborn)

Twenty minutes into a session, you gave Claude Code a clear constraint — “don’t touch the payment code,” “always use single quotes here,” “this package is off-limits, use the wrapper instead.” It followed the rule for a while. Then it didn’t. No error, no warning, nothing crashed. It just quietly stopped behaving like you said that.

If you searched “claude code forgets instructions,” “claude code ignoring what I said,” or “claude code stopped following my rules,” this is almost always the same root cause, and it isn’t the model being careless.

The mechanism: compaction, not carelessness

Claude Code has a finite context window — it can only hold so much conversation at once. As a session runs long, the tool history, file contents, and back-and-forth pile up, and eventually the session gets close to that limit. When that happens, Claude Code compacts: it summarizes the earlier part of the conversation into a condensed form so the session can keep going instead of hitting a hard wall. You’ll sometimes see a note in the output when this happens; you can also trigger it yourself with /compact.

Compaction is not truncation — it doesn’t just chop off old messages. It’s closer to what a person does when they skim a long meeting transcript and write a two-paragraph summary: the big decisions and overall shape survive, but a specific, only-said-once aside does not survive that process reliably. A rule you stated clearly but only mentioned a single time, early on, in passing, is exactly the kind of detail that’s easy for a summary to compress away — not because it didn’t matter, but because nothing about how you said it signaled “this is a permanent constraint, not a passing comment.”

That’s the actual difference between an instruction that survives a long session and one that doesn’t: whether it lives only in conversation history (compactable) or somewhere that gets re-supplied every turn regardless of compaction — which is exactly what a CLAUDE.md file is for.

How to tell this is what’s happening

1. Check whether the session is actually long. If you’re 10+ tool calls or a long stretch of back-and-forth into the same session, compaction is plausible. A rule dropped in the first two minutes of a fresh session is a different problem (worth double-checking you actually stated it clearly, not implied it).
2. Look for a compaction notice. Claude Code will often surface when it has compacted the conversation. If you see one between when you gave the instruction and when it stopped being followed, that’s your answer.
3. Ask it directly. Literally asking “what did I tell you about the payment code earlier in this session” is a fast, cheap diagnostic — a vague or generic answer where you expected a specific one is a strong signal the specific detail got compressed out.
4. Rule out the simpler explanation first. Before blaming compaction, confirm the instruction wasn’t ambiguous, wasn’t contradicted by something you said later, and wasn’t scoped to a file or task that’s no longer in play. Compaction gets blamed for plain miscommunication more often than it should.

What actually fixes it

1. Put durable rules in CLAUDE.md, not just the chat. Project-level instructions in CLAUDE.md get re-included as context on every turn — they aren’t sitting in conversation history waiting to be summarized away. Anything you’d be upset to have forgotten belongs there, not in a one-off message.
2. Restate critical constraints after a compaction happens. If you see the compaction notice, treat it as a checkpoint: re-state anything load-bearing that isn’t already in CLAUDE.md. It costs one message and removes the ambiguity entirely.
3. Break long sessions at natural task boundaries. Instead of one marathon session covering feature build → debug → refactor → docs, close out and start fresh between distinct chunks of work. A fresh session with the constraint restated (or already in CLAUDE.md) is more reliable than an old one that’s been compacted two or three times.
4. Make the instruction sound like a rule, not a comment. “Don’t touch the payment code” said once in passing competes with everything else in that turn. Calling it out explicitly — its own line, stated as a constraint — makes it more likely to survive a summary intact, though CLAUDE.md is still the more reliable fix for anything that truly can’t be violated.

What doesn’t help

• Repeating the instruction louder or in caps. Emphasis doesn’t change whether something lives in compactable history or not — only where it’s stored does.
• Assuming CLAUDE.md isn’t being read. That’s a real, separate failure mode, but it looks different: rules from CLAUDE.md fail from the very first turn, not gradually partway through a long session. If a rule worked for a while and then stopped, that points at compaction, not a CLAUDE.md loading problem.
• Starting a brand-new session for every small instruction. Overcorrecting into constant fresh sessions loses useful accumulated context for no reason — the fix is putting the specific durable rules in the right place, not avoiding long sessions altogether.
• Filing it as a bug. Compaction working as designed can feel like a regression in the moment, but it’s expected behavior for how any tool with a bounded context window has to manage a long-running conversation — the fix is where you put the rule, not a report against the tool.

How to verify you’ve actually fixed it

Add the rule to CLAUDE.md, then deliberately run the session long enough to trigger another compaction (or run /compact yourself), and check whether the behavior still holds afterward. If it does, the rule is now living somewhere compaction doesn’t touch. If you’re relying on restating it manually instead, the honest test is the same: get past a compaction event and confirm the constraint is still being followed, not just assume it is because nothing crashed.