Does your coding agent remember previous conversations?
short answer: no — but the conversations are still on your disk
Claude Code, Codex CLI, Cursor, Gemini CLI and the rest all behave the same way here. Inside one session the agent remembers everything you said. Start a new session and it knows nothing about the last one — not the bug you fixed together yesterday, not the approach you already tried and rejected, not the command that finally worked.
That is not a bug or a setting you forgot to turn on. An agent's memory is its context window, and the window is thrown away when the session ends.
What each agent actually keeps
Three different things get called "memory", and none of them is what you want on its own:
| Mechanism | Carries across sessions | What it holds |
|---|---|---|
| Context window | No | Everything in the current session, until it fills up |
Rules file (CLAUDE.md, AGENTS.md) | Yes | Only what you typed into it by hand |
| Session transcript on disk | Yes, but nothing reads it | Every turn, command and error, verbatim |
So the honest answer to "does it remember?" is: your agent wrote down everything that happened, and then never opened the file again. And Claude Code deletes that file after 30 days by default (cleanupPeriodDays) — see session files on disk for how to keep it.
Per agent
Every agent below writes a transcript you can read. "Resume" means the harness can re-open one specific past session and continue it; none of them search across sessions on their own.
| Agent | Remembers across sessions | Can resume one session | Transcript |
|---|---|---|---|
| Claude Code | No | Yes (--resume) | ~/.claude/projects/**/*.jsonl |
| Codex CLI | No | Yes | ~/.codex/sessions/**/rollout-*.jsonl |
| Cursor | No | Yes | state.vscdb (SQLite) and ~/.cursor |
| Gemini CLI | No | Yes | ~/.gemini/tmp/*/chats/ |
| Copilot CLI | No | Yes | ~/.copilot/session-state/*/events.jsonl |
| opencode | No | Yes | local database |
| aider | No | No | ~/.aider.chat.history.md |
| Zed | No | No | application-support database |
The format registry has all twenty-two, with the exact glob for each and what a record looks like.
"But it summarised the session — isn't that memory?"
Compaction is what happens when a long session runs out of window: earlier turns are replaced by a summary so the rest keeps fitting. The summary stays inside that session, and it is prose.
Measured over 43 real compactions from one machine's history (method and corpus in the benchmarks):
- 77% of the decisions survived the summary.
- 0.2% of the commands that had actually been run survived it.
Which matches what it feels like: the agent still knows you chose Postgres, and has no idea what the migration command was.
How to make it remember
Three options, in the order people usually try them.
1. Write it down yourself
A rules file is read at the start of every session, so anything in it is remembered forever. It is the right home for conventions, the build command, and things not to touch. It is a bad home for history: you have to predict in advance what will matter, and nobody writes down a problem they have not hit twice yet. See when CLAUDE.md grows.
2. A memory service
Memory platforms record facts from the moment you install them, usually through an extraction model. They start empty — the months you already worked are not in them — and they put a network call in a loop that did not have one. Compared here.
3. Read the transcripts that already exist
Nothing needs recording, because the recording already happened. An index over those files answers "have I seen this before?" including for every session from before you installed anything. That is what deja is:
curl -fsSL https://raw.githubusercontent.com/vshulcz/deja-vu/main/install.sh | sh deja install --auto
$ deja "connection pool exhausted" [claude] api · Jul 8 · 8f31c0a9 — 2 matches login started failing after refresh token rotation; jwt kid mismatch in tests fixed by reloading jwks cache after rotateKey and adding a clock-skew test [codex] web · Jul 1 · b77d91e2 — 1 match refresh token cookie needed SameSite=Lax in local callback flow
With auto-recall wired in, the agent runs that lookup itself — at session start, on a prompt that matches earlier work, before it edits a file or runs a command, and after a command fails. It is local: no account, no upload, no model call. Which agent supports which moment.
You do not need any of this to read your own history — the files are yours and they are plain text. What is in them · Finding one session · Getting started