Why Claude Code ignores your project rules (and how to make them stick)

You added a rule to CLAUDE.md three weeks ago. Something important, the kind of thing that burned you when Claude got it wrong: “never use em dashes in comments” or “always check the feature flag before adding a new config key.” You wrote it clearly. You tested it. Claude followed it perfectly.

Then you came back after a long session on a different branch, and Claude started doing the old thing again.

You grep the file. The rule is still there. You paste it into the chat directly. Claude acknowledges it, apologizes, and follows the rule for the next two responses. Then drifts again.

This is what context debt looks like in an AI-assisted project. Your rules are real, but Claude’s attention to them isn’t stable across long sessions, branch switches, or the invisible boundary between one conversation and the next.

The frustrating part is that this isn’t a bug in Claude. It’s a structural property of how large context windows work under load. When a session grows long enough, or when you reopen a project after a few days away, the model’s effective attention distributes across everything in context. A static CLAUDE.md competes with hundreds of messages, tool outputs, diffs, and error traces. Rules from the top of the file don’t disappear, but they stop landing with the same weight they had when the session was fresh.

There’s also the problem of stale rules. Projects evolve. An architecture decision you made in January is now wrong because you changed the data model in March. But your CLAUDE.md still says to use the old pattern, and Claude follows it faithfully. The rule is enforced. The rule is wrong. You won’t notice until something breaks in a way that’s hard to trace back.

What actually helps is making your project context dynamic rather than static. Instead of rules that live in a file and hope for attention, you want rules that are surfaced with recency, tied to the state of the codebase right now, and anchored to decisions that were actually made. Not a document you maintain by hand, but a layer that updates as your work evolves.

This is one of the things KeepGoing’s git hooks handle. When you commit, merge, or switch branches, a checkpoint captures what was just decided: the file, the reasoning if it’s in the commit message, the timing. When you start a new session, that context is there at the top, recent and specific rather than buried under three weeks of earlier notes. It doesn’t replace CLAUDE.md, but it gives Claude a clear signal about what’s changed since the rules were last written.

The fix isn’t to write better rules. It’s to accept that static rules need a dynamic layer to stay effective. Start by treating your CLAUDE.md as a living document: date your decisions, note when something changed and why, and prune old guidance when it no longer reflects the codebase. Then look at what triggers those updates automatically. The goal is a context that’s accurate when Claude reads it, not just when you wrote it.

Rules that age in silence are rules that cause mistakes. The solution isn’t perfect memory. It’s staying current.