--- title: "My AI Agent's Memory Was Per-Folder, So My Clones Never Learned From Each Other" canonical: https://dxdev.com/blog/git-tracked-agent-memory-not-per-folder/ datePublished: 2026-04-10 --- Claude Code stores its local memory at `~/.claude/projects//memory/`. That path has your working directory baked into it. I run the same project out of four clone directories. That meant four amnesiac agents that never shared a lesson, and I didn't notice until one re-learned something another had figured out a week earlier. This becomes more visible as soon as the same project is worked on from more than one checkout. ## How the key works, and why it scales into a trap In this setup, the memory store was keyed by the encoded current working directory rather than repository identity. Two directories therefore had separate local stores, with no automatic sharing between them. My codebase lives in clones I open as separate folders: four of them, call them clone1 through clone4. On a normal day I'll have several open at once because release, feature, and prototype branches are genuinely different working states and I 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`, `c--projects-clone4`, one per directory, case and drive letter included. Each session wrote and read its memory from a different one. So when an agent in clone4 worked out a non-obvious thing, that knowledge landed in clone4's memory bucket and stayed there. The agent in clone3 had no idea. Neither did the one in clone1. Neither did I, three clones over, and neither did any human teammate, because that store is on my machine under my home directory. It's not in the repo, it's not pushed anywhere, and nobody else can see it. This is more than a local quirk when a project uses multiple checkouts. Tool-local memory can still be useful for a session, but it is not a reliable place for project knowledge another checkout or collaborator needs. The more parallel the work becomes, the easier it is to re-derive a fact that already exists elsewhere. ## The companion failure: skills drift exactly like uncommitted code Memory was half of it. The other half was skills. Unlike memory, skills are committed to git. My `.claude/skills/` files are real tracked files. But "tracked" is not the same as "in sync." I found that all four clones had different mtimes on the same file, `.claude/skills/deploy/SKILL.md`, the skill that runs my deploy flow. Same file name, same path, edited in whichever clone I happened to be in and not always pushed before I moved on. The result 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 is still on the older copy. Nothing crashes, nothing tells you. It just quietly does the old thing. This is normal git hygiene applied to a thing devs don't automatically version. A skill that lives in the repo but gets edited in place across multiple checkouts drifts for exactly the same reason any uncommitted change drifts. You wouldn't expect a source file edited in clone4 to magically appear in clone2. The skill is no different, but because it's "config" or "AI stuff," the instinct to version it doesn't fire. ## The fix: treat agent knowledge like code, because it is The durable part of the solution is to give project knowledge a reviewed home in the repository, while keeping tool-local memory for session-specific scratch work. For memory, I made a Git-tracked learnings file the canonical home for anything worth carrying forward, alongside the rest of the shared AI context. The rule was simple: if the next session, another clone, or another developer would need it, record it in the reviewed project file. Local memory remained appropriate for within-session scratch work. Once that knowledge is reviewed, committed, and pulled through the normal Git workflow, it can reach the relevant clones and collaborators. The important distinction is that it now lives in shared project history rather than an opaque, directory-keyed local store. For skills, the same logic needs ordinary change discipline: make changes in a deliberate working branch, commit and review them, and update the checkout before editing an older copy. The failure was not that the skills were untracked; it was treating synchronizing those tracked files as optional. There's nothing exotic here. It's the version-control discipline you already apply to source, pointed at two things that don't look like source: the agent's accumulated knowledge and the agent's skills. Both are inputs that change behavior. Both should be versioned and pulled. ## A concrete instance from the same day The shared-knowledge file earned its keep immediately because it could hold operational facts with cross-checkout relevance. One example was that some database changes lacked a normal source-control trail. The durable project guidance should not be a manual production command; it should point to an auditable migration or controlled change record, rollback plan, and verification process. That is exactly the kind of project-level constraint that should not live only in one clone's local memory. A reviewed, tracked record makes the rule available to collaborators and future workspaces through normal version control. ## Related - [Writing an AI_CONTEXT.md So Your Assistant Stops Rediscovering Your Codebase](ai-context-md-stop-rediscovering-your-codebase): making project knowledge repository-resident rather than session-resident - [Your AI Skill File Is Part of Production Now](2026-04-03_ai-skill-is-production-infra): why agent instructions that change repeatable behavior deserve ordinary change control