Your coding agents forget your repo every time you switch. What a shared memory layer should do

Why do coding agents forget your repo?

Because they start from nothing. Claude Code's docs say each session begins with a fresh context window, and Cursor's say large language models don't retain memory between completions. Whatever an agent knows about your project has to be loaded from somewhere, and each tool has built its own somewhere.

Agents read the code well. What gets lost is everything the code doesn't say:

• Conventions the linter doesn't enforce: naming, where new modules go, which patterns are on their way out.
• Decisions and their reasons: why one library and not the obvious alternative, and what was tried and dropped.
• Preferences: how you write commits, when to run the tests, how much explanation you want.
• Where the work stands: what's half done, what's blocked, what you agreed to come back to.

The code tells an agent what the project is. It doesn't tell it what you've already decided.

What do CLAUDE.md, AGENTS.md and Cursor rules already do?

A lot, and it's worth knowing first. Each tool loads instruction files at the start of a session, at more than one scope:

AGENTS.md deserves a special mention. It's an open format, described on its site as a README for agents, and it's now stewarded by the Agentic AI Foundation under the Linux Foundation. Codex reads it before doing any work, Cursor supports it, and Claude Code reads it in place of CLAUDE.md when the repo has no CLAUDE.md. If you take one practical thing from this post, put your build commands and conventions in an AGENTS.md today.

Claude Code lets you browse and edit its memory with /memory, and ChatGPT lets you review, correct and delete what it remembers. Seeing what an assistant was told is the right default.

Where do memory files and rules files run out?

They give one tool instructions for one repo, and they do that well. The gaps show up when you work across tools:

• Each tool reads its own copy. Your personal preferences live in ~/.claude/CLAUDE.md, in ~/.codex/AGENTS.md and in Cursor's User Rules. Say it once per tool, then keep the copies in sync by hand.
• Project files are shared with everyone who clones. That's what they're for: Claude Code's docs describe the project CLAUDE.md as team-shared instructions and point personal, per-project notes to a gitignored CLAUDE.local.md. It's the right home for conventions and the wrong one for anything private.
• Learned memory stays on one machine. Claude Code's docs say auto memory is machine-local and isn't shared across machines or cloud environments.
• Files are scoped by path, not by reader. Any agent you run in a repo can load what is in it. There is no way to say that one assistant may read the project brief while another may not.
• Decisions need someone to write them down. The reasoning behind a choice usually lives in a chat with one tool, and it stays there.

How do you keep Claude Code memory across sessions?

Today, with two mechanisms. CLAUDE.md is what you write: the docs call it the place to write down what you'd otherwise re-explain. Auto memory is what Claude writes: your corrections and preferences, and project context it can't get from the code. Both load at the start of each session, and /memory shows you both.

The limit is that both belong to Claude Code. Open the repo in Codex the next morning and yesterday's decision isn't there unless you copied it into AGENTS.md. A memory layer should make that copy unnecessary: save a decision once, and the next session gets it whichever assistant opens it.

It should also stay readable. Memory an agent writes for itself can be wrong, and a wrong memory is worse than none, because the next session trusts it. You should be able to see it, fix it and delete it.

Can your agents' memory follow you across devices?

Partly. Anything committed to the repo travels with git, so a second machine gets your AGENTS.md and project CLAUDE.md on the next pull. Your user-level files live in the home directory of the machine you wrote them on, and Claude Code's auto memory, by its own docs, doesn't leave that machine. On a new laptop you start with the team's instructions and none of your own.

A memory layer should follow you from desk to laptop without making a cloud upload the price. Moving context between your own devices doesn't need a third party to hold a copy, and when a copy does go to a server, that should be your choice, not the default. Koru Workspace already syncs devices directly with each other, so I know the direct route can be built.

What should follow you across projects, and what should stay in one repo?

The tools already split this the right way. Claude Code's ~/.claude/CLAUDE.md holds personal preferences for all projects, every repository inherits Codex's global AGENTS.md, and Cursor's User Rules apply across all projects. Project files stay with their repo. The problem is only that the personal layer exists once per tool.

A memory layer should keep the two scopes explicit:

• Project memory belongs to one repo: build commands, architecture decisions, the constraints a client gave you. It should never show up in another project.
• Personal memory follows you everywhere: how you write commits, the languages you prefer, how you like code reviewed.

If you do client work, this matters: one client's decisions must not leak into another client's repo.

What should a shared memory layer for coding agents do?

Search for shared memory for AI agents and you mostly find papers on how agents share state. For a developer, the first question is simpler: who can read what? Here is my list:

• Save once, reuse it. A decision you explain to one assistant reaches the next without retyping.
• Work across sessions, devices and projects, the three places context gets lost today.
• Keep project memory scoped. What belongs to one repo stays there. What belongs to you follows you.
• Let you choose who reads what, per assistant and per person.
• Ask before sharing anything sensitive.
• Show you what's stored, and let you edit it.
• Private by default. Nothing is shared until you share it.
• No cloud upload by default. Your context stays on your devices unless you choose otherwise.
• Readable and portable. You can read it, export it and take it with you.
• Open standards. Connect through MCP, an open-source standard for connecting AI applications to external systems, and respect formats like AGENTS.md.

How are we approaching this with Koru Weave?

Koru Weave is our attempt at this layer, and it's in development: it isn't available yet. The teaser on its page says what it's for in a few lines: your plans, preferences and decisions. Saved once. Shared with the people you choose. And with the AI assistants you allow. Ask first. Keep the rest private.

Weave is designed to keep the context you choose to save in one place, where you can read and update it, and to let you select which people and compatible assistants may access particular context. The proposed controls for an assistant's request are allow, ask before sharing and keep private. A planned activity view shows what Weave shared and when, so you can remove access for future requests. We're building toward assistant connections through MCP, and we'll publish supported apps and setup instructions as integrations are tested.

Some of my principles above are open questions for Weave, and I'd rather say so. Local control is a design goal, but storage and hosting options are still being worked out, and we'll document storage, processing and encryption for each supported setup before access opens. Removing access will stop future access through Weave; it can't recall what a person or service has already received.

Weave is being designed as part of Koru, next to Koru Workspace, our free, open-source (MPL-2.0), local-first notes app with a local database and a local MCP server. We're exploring how the two will work together.

If you're tired of explaining your repo again, join the Koru Weave early access list for development updates and to hear when testing opens. Joining doesn't give access yet.

If you're curious how we build Koru itself, read how Koru is built: a native Rust app, not Electron. I post about what we're building on X as @liechti_dev.