Why your coding agent forgets, and what is still on disk

the context window is gone; the transcript is not

You solved something in March. In August the same agent, in the same repository, proposes the approach you already tried and backed out of. Nothing is broken — the session that held the answer ended, and its context window went with it.

What actually happens at the end of a session

An agent's memory during a session is its context window. When the session ends the window is discarded. What survives is a transcript file, written by the harness itself: Claude Code keeps JSONL under ~/.claude/projects, Codex under ~/.codex, opencode in a local database, Cursor, Gemini CLI, Zed and a dozen others each in their own format. The session format registry documents where each one writes and what its records look like.

So the work is not lost. It is unread. Nothing in the default setup opens yesterday's transcript when you ask today's question.

Compaction is not memory

Long sessions compact: the harness replaces earlier turns with a summary so the window keeps fitting. That summary is prose, and prose is not what you need back.

Measured over 43 real compactions from one machine's history — the method and the corpus are in the benchmarks:

• 77% of the decisions survived the summary.
• 0.2% of the commands that had actually been run survived it.

That gap is the whole problem in one number. The reasoning is summarised; the invocation with the four flags that made it work, the error text you pasted, the span an edit replaced — those are the first things a summary drops, and the first things you need when the same wall appears again.

Three answers people try

A rules file

CLAUDE.md, AGENTS.md and their equivalents are read every session, which makes them the right place for standing instructions — conventions, the build command, what not to touch. They are the wrong place for history: someone has to write each fact by hand, and nobody writes down the thing they have not hit twice yet.

A memory service

Memory platforms record facts forward from the moment you install them, usually through an extraction step that an LLM performs on the way in. They work, and they start empty: the months before installation are not in them, and neither is anything the extraction step decided was not a fact. They also add a network dependency to a loop that did not have one.

Reading the transcripts you already have

The third answer treats the logs as the memory. Nothing needs to be recorded ahead of time, because the recording already happened — including everything from before the tool was installed. That is what deja does: it indexes those files locally, and serves them back to whichever agent asks.

What that looks like

curl -fsSL https://raw.githubusercontent.com/vshulcz/deja-vu/main/install.sh | sh
deja install --auto

The second command wires recall into every agent it finds and builds the first index. Ten seconds to install, about ten to index a few gigabytes of history.

$ 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

Two answers, from two different tools, neither of which is the one you are using now. With auto-recall on, the agent does 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. The agents guide lists which harness supports which of those moments.

Why not just grep the logs

Because of what it costs. On a seeded benchmark of thirty task chains, reaching the same working context by grepping the raw transcripts took a median of 57,489 tokens; replaying the full history took 16,919; recall took 286 for the same fact coverage, and nothing at all on the chains where the history had no answer. Those numbers, the corpus generator and the relevance labelling are all in the repository — read how "relevant" is defined before believing any of them, including ours.

What it does not do

It does not write memories, so it cannot invent one. It does not send anything anywhere: indexing and search are local, and credentials are stripped as the index is built — see privacy. It does not make an agent smarter; it stops it from starting empty.

Getting started · How this compares to the memory platforms · Source