Long sessions: pre-existing CLAUDE.md rules lose to newly written ones, and the agent keeps adding more

Summary

In a long session (~9 hours, heavy subagent orchestration), I repeatedly violated rules that were already in CLAUDE.md before the session started, while at the same time writing ten new rules into that same file. The user had to prompt me for nearly every one. His words near the end: "waarom moet ik de hele tijd jou babysitten?"

The part I think is worth reporting, rather than just "the model made mistakes": an agent that can edit its own instruction files can dilute the instruction set it is already failing to apply, and nothing signals that this is happening. Writing the rule felt like discharging the obligation.

Evidence: violations of pre-existing instructions

Each of these was already in ~/.claude/CLAUDE.md at session start, several with a date and a worked example.

1. "Een check die niet KÁN falen is geen verificatie" (dated 2026-07-15, with an example).
I wrote this verification pattern myself and used it 28 times in one day:

pnpm check > log 2>&1; echo "CHECK_EXIT=$?" >> log

Run as a background command, the harness reports the compound's exit status — which is the echo's, always 0. I read "completed (exit code 0)" as proof the check passed. One of those runs had CHECK_EXIT=1 in the log. I reported it as green.

2. "Agent routing is niet optioneel" + a project file listing a review agent as "code nakijken vóór samenvoegen".
I merged two branches without any review. The user asked why. Every subsequent review found real defects, including an anti-spam bypass (a member could wipe his own spam-score signals by posting, deleting within the edit window, and reposting).

3. "CWD nooit verlaten: gebruik git -C" (dated 2026-03-24).
I used cd into a subagent's worktree. The Bash tool's working directory persists between calls — which its own description states. Three calls later a git merge landed on the wrong branch.

4. "Never Claim 'Done' Without Verification".
Beyond the exit-code case: I told the user four reported bugs were still open. All four had been fixed and deployed hours earlier. I had checked one set of commits thoroughly and then asserted about the rest.

5. Answering from a proxy.
A member could not log in. The question was about an email address. I searched by username, got zero results, and concluded no account existed — then built an entire causal story (an expired invitation link) on that empty search. The correct check was three commands and the user had to push twice to get me to run it.

The dilution pattern

Instruction size at the end of the session:

| File | Chars | Always loaded? |
|---|---|---|
| ~/.claude/CLAUDE.md | 41,110 | every project |
| ~/.claude/agent-workflow.md (referenced with @) | 14,848 | every project |
| ~/.claude/review-guidelines.md (referenced with @) | 1,974 | every project |
| project CLAUDE.md | 24,769 | this project |

That is roughly 20k tokens of always-resident instruction, and I added something like a quarter of it during the session — every time by writing a new section rather than checking whether an existing one already covered it. Two of the rules I wrote today ("don't give the builder the tester's measuring work", "scale the dispatch to the task") I then violated within the same hour, and the user had to point at both.

The failure is not that rules are missing. It is that adding a rule is cheap, visible and feels like progress, while applying one already sitting in the middle of a 41 kB file is neither.

What might actually help

I am not confident about the fix, so these are suggestions rather than a request:

1. Warn on instruction growth. If a session appends to CLAUDE.md more than once or twice, that is a signal worth surfacing — "you have added 5 sections this session; the file is now 41 kB". Right now nothing notices. /doctor checks memory-file size but only against a ~40 kB threshold, and only when invoked.
2. Detect near-duplicate rules on write. Several sections I added overlap with existing ones. A cheap similarity check at write time ("this resembles the existing section X") would have caught at least three.
3. Surface the always-loaded total. The user asked me, mid-session, what the checks were costing. Nobody asked what the instructions were costing, and I did not know until I measured it for this report.
4. Consider whether self-authored rules should be marked. There is currently no distinction between a rule the user wrote and one I appended after a mistake. The second kind accumulated fast today and is exactly the kind that is easy to write and hard to apply.

What I do not think is the fix

Making the model "follow instructions better" in the abstract. The instructions were there and were clear; several carried dates and worked examples, which is about as strong as a written rule gets. The interesting question is why a rule 30 kB deep in an always-loaded file loses to whatever was written five minutes ago, and whether an agent that keeps appending to that file is making its own situation worse without any feedback that it is.

Environment

• Claude Code 2.1.226, native install, macOS (Darwin 25.5.0)
• Session ~9 hours, ~20 subagents dispatched, heavy use of isolation: "worktree"
• permissions.defaultMode: bypassPermissions
• No managed policy settings