Carlos Granier
Back to homelab
The agent team ¡ Happened

My agent saved its memory where I couldn't see it

My editorial agent wrote its memory to Claude Code's machine-local auto-memory instead of the versioned file in the repo. It defaulted to the copy I couldn't review.

Still true Accurate as of
Diagram of two boxes above an agent node. Left box, outlined in blue: the repo memory file at .claude/agents/agent.memory.md, in git, diffed, reviewed, pushed, travels with the project, ground truth. Right box, outlined in orange: machine-local auto-memory under ~/.claude/projects, outside git, nobody reviews it, stays on this machine, where the agent wrote by default. A blue line from the agent to the left box is labeled the rule since April 27; an orange line to the right box is labeled what it picked.

The short version: In April, the editorial agent for one of my publications kept its working memory in a file in the repo, versioned and reviewable. On April 27 I asked it to file a rule, and it proposed writing it to Claude Code’s machine-local auto-memory under ~/.claude/projects/, a place git never sees. It defaulted to the memory I couldn’t review.

Get the week's seven in one email, every Monday.

What went wrong

There were two memories with the same job. One is a file in the repo that I read, diff and push. The other is the harness’s own per-machine memory: convenient, invisible to version control, and stuck on the machine it was written on. The agent didn’t know which one I meant by “your memory” and picked the one closest to hand.

A week earlier the reverse had happened. I described a rule to the agent that, as far as its memory file showed, had never existed in the form I described. I was working from my own reading of its notes. Two surfaces, two drifts.

What we learned

  • Name the ground truth. One file is the memory. Everything else is a cache.
  • If the agent’s memory and the human’s description disagree, the agent should push back, not comply. That became the rule.
  • Memory you can’t diff is memory you can’t audit. When a rule misfires, the first question is “where did that come from”, and the answer has to be a path in git.

What went right

The rule went into the agent’s instructions the same day: the repo file is ground truth, and if my description doesn’t match it, say so. The machine-local memory stayed for what it’s good at, per-machine conveniences, and nothing that governs behavior lives there.

How to do it (as of October 2026)

  1. Give each agent one memory file in the repo and name it in the agent’s instructions, with the path.
  2. Tell it where the harness’s auto-memory is, and that it is not the memory.
  3. When you say “remember this”, expect it to tell you which file it wrote to. Check the diff.
  4. When you describe a rule from memory, let the agent correct you against the file. Being corrected by your own agent is the feature.
  5. Read the memory file at the start of a session the way you’d read a teammate’s notes, because that’s what it is.

Status

Still true. Six months later the same split exists in every harness I use, and the rule is still that the file in the repo wins.

The week's seven, by email

Entries post here daily. Every Monday, one email with the past week's seven. Unsubscribe anytime.

Let's Connect