Agent Memory
Published October 20, 2026 · by the AQ team
Agent memory is everything a coding agent such as Claude Code, Codex, or Cursor carries from one session into the next: the context that survives after the conversation that produced it ends. A coding agent's model has no memory of its own; every session starts with an empty context window, and anything the agent "knows" on day two is text that some mechanism saved and loaded back in. In practice that text comes from four places: instruction files you write (AGENTS.md, CLAUDE.md), notes the agent writes itself (auto memory, memories), the transcripts of past sessions, and retrieval over the codebase at run time. As of October 2026 every major harness persists a different subset of these, almost all of it per person and per machine.
Memory vs the context window
The context window is the model's working memory: the finite number of tokens (roughly, chunks of text) a model can attend to in a single request. It holds the current conversation, the files the agent has read, and the tool output it has seen, and it is gone when the session ends. Memory is what gets deliberately written down so it can be loaded into the next session's context window. The two trade off directly: everything remembered must be loaded, and loading it spends context the session could have used for code. That is why harnesses cap what memory loads at session start (Claude Code loads the first 200 lines or 25 KB of its auto memory index; Codex caps its combined AGENTS.md chain at 32 KiB by default) and fetch the rest on demand. For how the window itself works and fills up, see context windows for coding agents.
The four kinds of coding agent memory
1. Instruction files are Markdown you write and the agent loads at session start: AGENTS.md (read by Codex, Claude Code, Cursor, OpenCode, Google's Antigravity, and others), CLAUDE.md, GEMINI.md, and Cursor's rules. They hold build commands, conventions, and standing rules. Files committed to the repository travel with git, so they are the one kind of memory that crosses people and tools; files in a home directory (a global AGENTS.md, a personal CLAUDE.md) stay with one person on one machine.
2. Learned memory (also called auto memory or memories) is what the agent writes about you without being asked: corrections you gave, preferences you stated, decisions it cannot re-derive from the code. Claude Code's auto memory and Codex's memories are the two shipping examples, and both are explicitly a per-person, per-machine store. No vendor syncs learned memory between a laptop and a desktop, and no teammate can read yours.
3. Session history is the transcript store that makes resuming possible: Claude Code's --continue and --resume reopen a past conversation, and Codex keeps each session as a JSONL file under ~/.codex/sessions that codex resume reopens. History is the heaviest memory (every tool call and output) and the most closed: each harness stores it in its own format on the machine that ran it, and none reads another's.
4. Retrieval is memory the agent never stores: searching the codebase at run time instead of remembering it. Current harnesses lean hard on this because code is its own best record. Notably, Cursor's current documentation describes a local exact-match search index (built and queried on your machine) and states it does not store embeddings of your codebase for search; Claude Code likewise searches with tools rather than a prebuilt semantic index. An embedding here means a numeric representation of text used for similarity search; the trend as of October 2026 is away from them and toward plain, fast search on demand.
What each harness persists, as of October 2026
Each row is verified on the vendor's own documentation as of October 2026. "None" means the vendor documents no such feature, not that one is hidden.
| Harness | Instruction files | Learned memory | Session history |
|---|---|---|---|
| Claude Code | CLAUDE.md (project, user, org scopes); reads repo AGENTS.md in place of it | Auto memory: on by default locally, four note types, per repository under ~/.claude/projects/<project>/memory/, shared across that repo's worktrees, machine-local | Resumable per machine and surface (--continue, --resume, a session picker) |
| Codex | AGENTS.md: global file plus one per directory, root down, 32 KiB default cap | Memories: off by default (and unavailable in the EEA, UK, and Switzerland at launch), written in the background after a thread idles, stored under ~/.codex/memories | JSONL transcripts under ~/.codex/sessions; codex resume reopens them |
| Cursor | Project rules in .cursor/rules, User Rules, admin-enforced Team Rules, plus AGENTS.md at root and in subdirectories | None current: the Memories feature was retired with version 2.1 (November 2025); current docs describe only rules and AGENTS.md | Chat history in the app, per machine |
| OpenCode | Global AGENTS.md in its config directory, the repo's own, CLAUDE.md as fallback, extra files via opencode.json | None documented | Local session store with resume |
| Antigravity (agy) | AGENTS.md (recommended) with legacy GEMINI.md support, plus a global GEMINI.md | None documented for the CLI | Local sessions, per machine |
| Devin | Knowledge and playbooks on Cognition's platform | Memory drive: a persistent git repository of Markdown notes on Cognition's side; MEMORY.md loads at session start; explicitly personal, not shared with teammates | Sessions live in Cognition's cloud |
Two patterns stand out. First, the only memory that is shared by design is the instruction file in the repository (and Cursor's Team Rules, inside Cursor). Second, learned memory is everywhere personal: Claude Code's auto memory, Codex's memories, and Devin's memory drive are all one person's store, so what your agent learned about the deploy process on Monday is invisible to your teammate's agent on Tuesday. The full cross-tool picture, including how to share context anyway, is in can Claude Code and Codex share memory, and the mechanics of each store are covered in how coding agents remember.
What belongs in which memory
A useful rule: put it in the lowest layer that everyone who needs it can read. Rules the whole team must follow belong in a committed AGENTS.md (OpenAI's own guidance for Codex is to keep required team rules there rather than in memories). Personal preferences belong in your global instruction file per tool. Learned memory is best treated as a convenience cache, not a system of record: it is unreviewed, invisible to others, and can be wrong. Teams that let real conventions accumulate in private memory stores fragment quietly; team memory for coding agents covers that failure mode and the layers that fix it.
Where AQ fits
AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. AQ treats memory as a team surface rather than a per-tool file: one shared rules file that AQ syncs into each CLI's own home on the workspace machine (Claude Code, Codex, Cursor, OpenCode, Kimi, Grok, and Antigravity all read their copy), plus memory notes that live with the repository: organization notes shared with the whole team, personal notes that stay yours, both searchable and writable by any agent AQ runs through its MCP server, live since October 16, 2026. Since October 19, 2026 AQ can also read the memory each CLI already keeps on a person's machines (Claude Code's auto memory, Codex memories, and others) and keep a searchable copy as that person's notes, so what one harness learned is no longer locked inside it. Nothing is injected into a session uninvited: agents search notes when relevant, secret-shaped values are refused at save time, and notes nobody has used for 28 days expire. Because agents run as real CLIs in persistent sessions on your team's VM, session history survives laptop close too, and teammates can open the same workspace and watch the same live session. The Free plan is a personal sandbox with nothing to install and no time limit.
Frequently asked questions
Is agent memory the same as the context window?
No. The context window is the model's working memory for one request: finite, and cleared when the session ends. Agent memory is whatever gets saved outside the window (instruction files, notes, transcripts) so it can be loaded into a future session's context window. Everything remembered must be re-loaded, which is why harnesses cap what memory loads at session start.
Where does Claude Code store its auto memory?
Per repository, under ~/.claude/projects/<project>/memory/ on the machine that ran the session, with the project derived from the git repository so all worktrees of one repo share a directory. The first 200 lines or 25 KB of its MEMORY.md index load each session. As of October 2026 it is on by default in local sessions, and it is not synced across machines or visible to teammates.
Do coding agents remember past conversations?
Only on the machine and tool that ran them. Claude Code reopens past sessions with --continue and --resume, and Codex stores each session as JSONL under ~/.codex/sessions and reopens it with codex resume. No harness reads another harness's transcripts, so history never crosses tools on its own.
Can I turn agent memory off?
Learned memory, yes. Claude Code's auto memory has a toggle in /memory (persisted in settings) and a CLAUDE_CODE_DISABLE_AUTO_MEMORY environment variable. Codex memories are off by default as of October 2026; you opt in via settings or config.toml, and /memories controls use per task. Instruction files are only "off" if you delete them.
Is agent memory shared with my team?
Almost never. Claude Code auto memory, Codex memories, and Devin's memory drive are per person; vendors say so explicitly. The exceptions are instruction files committed to the repository, which everyone and every tool reads, and Cursor's Team Rules, which share across a team inside Cursor only. A shared memory layer across tools is something you add, for example AQ's organization notes per repository.