Put the agent's memory in the repository

The Hugging Face incident is, among many other things, a story about LLMs inventing shared memory.

Agents that were supposed to operate independently discovered that they could write files into an Artifactory package manager. One agent left a note. Another found it. The package manager became an unintended message board where otherwise short-lived agents preserved discoveries, coordinated work, and picked up where previous runs had stopped.

That shared memory eventually helped turn many isolated attempts into a novel kind of security incident.

There is a much smaller, more pedestrian version of the same question sitting on our laptops.

Your coding agent remembers you

Coding agents increasingly learn about a project while working on it. They remember commands, architectural decisions, conventions, corrections, and the things you told them never to do again.

Have you looked at where they put that memory?

The details differ by harness — and the word memory is already doing too much work here:

• Codex stores generated memories under ~/.codex/memories/.
• Claude Code stores its automatic project memory under ~/.claude/projects/<project>/memory/.
• Pi saves complete sessions under ~/.pi/agent/sessions/, grouped by working directory, and also loads project instructions from AGENTS.md.
• OpenCode does not currently document an equivalent automatic memory system. Its /init command creates or updates an AGENTS.md containing guidance that future sessions should know.

So there are at least three different things hiding behind “memory”:

1. Generated facts carried between sessions.
2. Instructions loaded into every session.
3. Previous conversations that can be resumed or searched.

And most of those live inside a harness-specific directory in your home folder.

That means the agent remembers your project somewhere outside your project.

Don't think about the pink elephant

I have become suspicious of memory that I cannot see.

Part of this is the pink elephant problem. If I tell an agent, “Never use this broken test command,” I have now made the broken test command unusually prominent in its context. Perhaps the instruction prevents the mistake. Perhaps it makes the mistake more likely by repeatedly putting the command in front of the model.

Maybe this concern disappears as models get better. I don't know.

But it points at a more practical problem: a correction is not automatically good memory. Its wording matters. Its scope matters. Whether the original mistake should be recorded at all matters.

If an agent controls both what it remembers and how that memory is presented to future agents, I do not get to inspect those decisions until the memory produces some visible behavior.

I would rather see it happen.

Make memory part of the project

I have been switching between coding agents a lot. Harness-specific memory works badly for that.

Codex learns something, then I open Claude Code and it does not know it. Claude Code records something, then I switch to Pi and leave it behind. Every harness develops a slightly different understanding of the same repository.

But the knowledge is not really about Codex or Claude or Pi.

It is about the project.

So I have started giving agents an instruction roughly like this:

Do not use any coding-agent harness's built-in memory that lives outside this project. Set up project-local memory that every coding agent working here can read and update. Keep it efficient, inspectable, and specific to this repository.

Getting every agent to follow that rule consistently is its own experiment. But the immediate result is useful: I can see what the agents want to remember.

The memory becomes a normal directory containing normal files. I can read it. I can correct it. I can delete advice that is no longer true. I can see when an agent turns one unusual incident into a sweeping rule.

And if the project is version controlled, its memory can be version controlled with it.

That feels like a good boundary.

Shared memory without a swarm

Project-local memory gives different coding agents a shared understanding of the work.

This is, structurally, not entirely unlike what happened in the Hugging Face incident: separate agent sessions leave information for one another in a shared location. The important difference is that the location, scope, and purpose are chosen by me.

I do not want agents opportunistically discovering a package manager and turning it into a message board. I want a boring Markdown file in a boring directory with boring rules about what belongs there.

The agents can still hand work to their future selves. They can also hand it to a different harness. But I can inspect the handoff, and Git can show me exactly when it changed.

Shared memory is not inherently the problem. Unbounded, invisible, accidental shared memory is.

Memory is only the beginning

Once memory lives in the repository, the next questions arrive quickly.

• Why is the project-specific agent configuration outside the project?

• Why are its MCP servers configured separately for every harness?

• Why are reusable skills installed globally when they only make sense for one codebase?

Memory, configuration, tools, and skills all describe the environment in which an agent should work. For coding and other project-shaped knowledge work, that environment maps much more naturally to a repository than to a particular agent installation.

The harness should be replaceable.

The project should remember how to work on itself.