Why Our Agent Kept Re-Learning a Lesson Another Clone Already Had

Claude Code stores its local memory at ~/.claude/projects/<encoded-cwd>/memory/. That path has your working directory baked into it. We run the same project out of four clone directories, so we had four amnesiac agents that never shared a lesson. We only noticed when one of them re-learned something another had figured out a week earlier.

The problem shows up as soon as more than one checkout of a project is in use.

How the key works, and why it turns into a trap

The memory store is keyed by the encoded current working directory. It isn’t keyed by repository identity. Two directories get two separate local stores, with no automatic sharing between them.

Our codebase lives in four clones that we open as separate folders. Call them clone1 through clone4. On a normal day several are open at once, because release, feature and prototype branches are different working states and we don’t want them stepping on each other. On a busy day the calendar shows five Claude sessions spread across three of those clones. The encoded buckets look like c--projects-clone1, c--projects-clone3 and c--projects-clone4, one per directory, case and drive letter included. Each session reads and writes memory in a different one.

So when an agent in clone4 worked out a non-obvious fact, it landed in clone4’s bucket and stayed there. The agent in clone3 had no idea. Neither did the one in clone1. Neither did we, three clones over. No human teammate could see it either. That store sits on one machine under a home directory. It is not in the repo and it is not pushed anywhere.

Tool-local memory is fine for a single session. It is a poor home for project knowledge that another checkout or another person needs. The more parallel the work gets, the easier it is to re-derive a fact that already exists in a bucket you can’t see.

Skills drifted the same way

Memory was half of it. The other half was skills.

Skills are committed to git. Our .claude/skills/ files are real tracked files. But tracked and in sync are different things. All four clones showed different mtimes on the same file, .claude/skills/deploy/SKILL.md, the skill that runs our deploy flow. Same name, same path. It had been edited in whichever clone we happened to be in, and not always pushed before we moved on.

That is the worst kind of drift. The “same” skill behaves differently depending on which clone you invoke it from. Fix a bug in the skill in clone4, run it from clone2 the next morning, and the bug is back, because clone2 still has the older copy. Nothing crashes and nothing warns you. It just does the old thing.

You would never expect a source file edited in clone4 to appear in clone2 by itself. A skill file is no different. Because it feels like config or “AI stuff,” the instinct to version it doesn’t fire.

Giving the knowledge a reviewed home

The durable fix is to give project knowledge a reviewed home in the repository and keep tool-local memory for session scratch work.

For memory, we made a git-tracked learnings file the canonical place for anything worth carrying forward, next to the rest of the shared AI context. The rule is simple. If the next session, another clone or another developer would need it, it goes in the reviewed project file. Local memory stays for within-session scratch.

Once an entry is reviewed, committed and pulled through the normal git workflow, it reaches the clones and collaborators that need it. It now lives in shared project history instead of a directory-keyed local store nobody else can open.

For skills, the fix is ordinary change discipline. Make changes on a deliberate working branch, commit and review them, and update the checkout before editing an older copy. The skills were tracked. The failure was treating the sync of those tracked files as optional.

None of this is exotic. It is the version-control habit we already apply to source, pointed at two things that don’t look like source: the agent’s accumulated knowledge and its skills. Both change behavior, so both get versioned and pulled.

The same day, a first entry

The shared file earned its keep right away, because it could hold operational facts that matter in every checkout. One example was that some database changes lacked a normal source-control trail. The durable guidance for that should not be a manual production command. It should point to an auditable migration or controlled change record, with a rollback plan and a verification process.

That is the kind of project-level constraint that shouldn’t live in one clone’s local memory. As a reviewed, tracked record, it is available to collaborators and future workspaces through normal version control.

What to check on your own setup

If you run an AI coding assistant from more than one checkout, find out where its accumulated knowledge is stored and whether anyone else can see it. Put what the next session or collaborator needs into a reviewed, tracked project file. Keep local memory for scratch work. Commit skill files like source, and update the checkout before you edit them.

dxdev LESSON · paste into your AI coding agent
LESSON: Agent memory is per-folder, not per-repo
SOURCE: dxdev.com/blog/git-tracked-agent-memory-not-per-folder
WHAT HAPPENED: Claude Code keys its local memory store to the encoded working directory path, not to the git remote or repo identity. Running the same project from four clone directories produced four isolated memory buckets that never shared a lesson. Skills committed to git drifted across clones because they were edited in whichever directory was open and not always pushed, so invoking the "same" skill from a different clone silently ran the older copy.
THE RULE: Any agent knowledge worth keeping must live in a git-tracked file inside the repo, not in tool-local per-folder memory.
CHECK MY CODE, then report PASS / FAIL with file:line for each:
  1. Does this project use Claude Code (or any per-folder-keyed agent memory) across more than one checkout or clone directory?
  2. Are agent memory writes going to the tool-local store (~/.claude/projects/...) rather than to a tracked file in the repo?
  3. Are agent skill or config files (e.g. .claude/skills/) edited in place across multiple checkouts without a mandatory pull-before-edit discipline?
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.