ai-memory: Shared Memory for Claude Code and Codex

Background and Context

Most coding agents now ship with some form of memory. Claude Code keeps notes, Cursor remembers certain facts, and other platforms keep adding similar features. These memories share one limit. The notes live on a single machine and belong to a single agent. If you switch tools, or hand the task to a colleague, the notes disappear from view. You then have to explain the architecture again, list the approaches that already failed, and restate the questions that remain open.

ai-memory targets exactly that gap. It is an open-source project written in Rust, with a rust-toolchain.toml file, tagged releases, a website at aimemory.sh and an open-source licence. On GitHub it has close to ten thousand stars. The project does not try to be another agent. It sits underneath all the agents as a shared layer of long-term memory.

The stated goal is simple. Suppose you quit Claude Code halfway through a task, then start OpenAI Codex in the same directory. Codex should be able to continue the work without a new briefing. That scenario defines the product.

Deep Analysis

How does ai-memory let Claude Code and Codex share one memory? The answer has four parts, and each one is a design choice with a clear reason. The first part is cross-agent coverage. More than twenty harnesses feed the same memory, including Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Grok, Devin, Kimi and Kiro. Progress moves between them through a typed handoff protocol. Every handoff has an owner, and it can be claimed only once. It records how far the last agent got, what failed, and what is still unresolved. The single-claim rule matters: two agents cannot both pick up the same piece of work by accident.

The second part is the `ai-memory run` command, which launches an agent and carries the session itself, not only a summary. For example, after you quit Claude Code, you can run `ai-memory run codex`. Codex receives the shared workflow plus a private, temporary local projection of the native history that Claude could see. That projection fills in exact details that the startup bundle had to cut. The remote server receives only the harness and session identifiers. It does not receive the path or the body of any local transcript file. The third part is the data format. The source of truth is a git-managed wiki made of plain .md files. You can grep it, open it in Obsidian, edit it by hand or copy it with rsync. The database is a derived index that can be rebuilt from the files at any time. There is no vector store to maintain, and nothing is locked inside a binary. The fourth part is silent capture. Lifecycle hooks record prompts, tool calls and session boundaries. A typed privacy boundary cleans the data before it is stored, and the server then turns it into readable pages. The default path makes zero LLM calls. Capture, search and handoff need no API key. Memory also decays on a tiered schedule that you can tune, and that process does not depend on an LLM either.

Industry Impact

The project covers four practical scenarios. The most typical one is switching tools in the middle of a task. You may be halfway through work in Claude Code when you hit a quota or a preference problem. You continue in Codex, and the next agent receives the handoff note directly. The second scenario is cross-project preference. A small personal profile records your usual package manager, test layout and architecture habits. It is delivered at the start of a session in a new repository. Its priority is lower than each repository's own rule files, so it acts only as a default. It is on by default for a single user. On a shared server you must turn it on yourself, and it is isolated per person. The details are in docs/cross-project-profile.md.

The third scenario is cross-machine work. The memory lives on a server that you run yourself. That can be the same laptop, a home server or another host. A project you stopped on a desktop can continue on a laptop, with the same knowledge and the same open questions. The fourth scenario is team sharing. Everyone points at the same server, and whatever one person's session learns becomes searchable by every agent. Knowledge is shared per project, while personal handoffs stay private. Multi-user authentication, per-person attribution and audit logs are built in. They are not part of a paid tier. For the wider industry, the meaning is a shift in ownership. Memory stops being a private feature of one vendor and becomes infrastructure that the engineering team controls. As teams run more agents, switching between them becomes routine, and nobody wants to be locked into one. Keeping the source of truth in plain text and git makes memory reviewable, portable and compatible with existing version control. That suits teams that care about traceability. The privacy design also deserves credit. The typed boundary and the identity-only upload in run mode show restraint, which is what sensitive code context requires.

Outlook

Several points need care. Covering more than twenty harnesses means following each vendor's hooks and session formats over time. The compatibility maintenance cost is not small. In shared team mode, the users themselves must decide which content should be searchable and how permissions are divided. The README, as summarised here, describes only part of the feature set. Details such as the decay policy should be checked against the official documentation.

Two questions are worth watching next. The first is whether more tools will accept the handoff protocol as a de facto standard. The second is how the zero-LLM default path performs at retrieval in large repositories, where plain-file search has to scale without a vector store. For individuals and teams who already use several coding agents, ai-memory offers a concrete and inspectable answer to the re-explanation problem. Its real value will show in daily use, in how often a second agent can truly continue the first agent's work without a new briefing.