Why AI Coding Assistants Forget Your Codebase Between Sessions
Claude Code, Cursor, and Codex do not remember yesterday.
The fix is not a longer prompt file.
It is a persistent context layer the assistant can re-enter on every session.
What this covers
- LLM-based coding assistants are stateless by default. Closing the window deletes the working context.
- In-session context also degrades. Compaction summarizes early turns and the model loses signal on the original task.
- A team-owned context layer at the file system path of the work is what survives a /clear, a /compact, a tool switch, or a new teammate joining.
- Pathrule is one implementation: path-scoped memories, rules, and skills delivered at hook time before the first tool call.
Comparison
| What persists | In-session only | Cross-session |
|---|---|---|
| Conversation history | Yes, until /clear or window closes | No |
| Files read into context | Yes, but compacted as the window fills | No |
| CLAUDE.md or AGENTS.md guidance | Loaded at start, never enforced mid-session | Yes, re-read every session, in full |
| Auto memory notes the model writes for itself | Yes | Yes, but only on the same machine |
| Path-scoped team memory | Yes | Yes, across machines, tools, and teammates |
The model is stateless. The session is not the model.
A working session feels continuous. The assistant remembers your last instruction, references files it read three messages ago, and follows the thread. That continuity is the session, not the model. The model itself has no memory of you between calls.
When the session closes, that working state goes with it. The next session starts from the same baseline as a session that has never run in your repo before. The assistant has weights, the prompt file at the root, whatever the tool injects, and the first message you type.
This is true for Claude Code, Cursor, Codex, Windsurf, and every other LLM-based coding assistant. They share the same architectural constraint. The product polish on top hides it well, until the moment a teammate joins or you reopen the project a week later and the assistant is back to asking obvious questions.
In-session memory also degrades
Forgetting does not only happen at session boundaries. Inside a long session, the context window fills. The tool then compacts older turns into summaries to keep the working set under the model limit.
Compaction is not lossless. The summarized turns lose detail, ordering, and emphasis. Practitioners report that early instructions feel less binding after a compaction. The model has read a summary of your rule, not your rule.
A /clear command is sharper. It deletes the working state intentionally. That is sometimes the right move for cost reasons. It is also another moment where context the team needs has to come back from somewhere outside the chat.
CLAUDE.md and AGENTS.md help, with a ceiling
A root prompt file is loaded at the start of every session. That makes it the most reliable cross-session carrier in a default setup. Teams that write a careful CLAUDE.md or AGENTS.md get a real lift from it.
The ceiling shows up as the file grows. Past one to two hundred instructions, the model treats later items as background. Past a certain length, the file no longer reflects the team because nobody reads it end to end before editing it. The carrier still works. The signal does not.
The other limit is scope. A root file applies everywhere. A schema note that matters in one folder is loaded into every session in every other folder, where it is noise.
Auto memory is local, not team
Claude Code and similar tools support auto memory: notes the assistant writes for itself based on corrections and preferences. These persist across sessions on the same machine.
For a solo developer this is genuinely useful. The assistant accumulates a private notebook about how you work. For a team it is a different story. Auto memory is per machine, per user, often per project root. It is not visible to teammates, not reviewable, and not portable to a different tool.
A new teammate joining the repo gets none of that learned context. Their assistant starts from the same zero state the original developer started from a year ago.
The shape of a real persistence layer
Cross-session context that survives /clear, /compact, a machine switch, and a new teammate has a few specific properties. It is stored outside the assistant. It is scoped to the path where it applies, not loaded globally. It is reviewable like code, with a change history and an owner. It reaches the assistant at hook time, before the first tool call, as system context.
Pathrule is one implementation of that shape. Team memories, rules, and skills live at paths in a workspace tree that mirrors the repo. Retrieval walks from the active path up the ancestors. The slice arrives in milliseconds from a precomputed local cache.
Open the project tomorrow, open it on a different laptop, hand it to a teammate who has never seen it before. The assistant gets the same path-scoped context every time. That is what cross-session means in practice.
A small test you can run this week
Pick one folder where the assistant repeatedly makes the same mistake. Write one Pathrule memory or rule attached to that path. Close the session. Open a new one in that folder tomorrow.
If the assistant behaves differently on the second session without you repeating the context, the persistence layer is working. If it does not, you have a clear next signal: the memory was wrong, the scope was wrong, or it was not delivered. Each of those is a real, debuggable answer instead of a vague feeling that the assistant is unreliable.
Every signup gets three months of Pathrule PRO on the house. If you want help designing the first persistence test on a real repo, [email protected] is open.