What survives when AI agents restart: five coding tools, checked against their own docs
"My LLM agents forget conversation history when I restart them, how do I fix this?" The question is asked constantly and contains a mechanical error worth clearing before any fix: every one of the five coding tools checked here already ships a working way to reopen the previous conversation. Nothing is broken. The gap people are actually hitting is narrower, and naming it precisely is the point of this comparison.
TL;DR
- Resume exists everywhere. Claude Code, Cursor, Codex, VS Code and Windsurf all document a command or a list that reopens a previous session. If the complaint is literally "my history is gone", it is usually still on disk.
- The real gap is the new session. Claude Code states it outright: each session begins with a fresh context window. A new task, a new terminal, a different day, and none of the five carries the earlier conversation into it.
- Resume is not a perfect rewind either. All five document compaction. What each keeps and drops differs by design, and two of the five decline to say what is dropped at all.
- Three of five ship cross-session memory in the editor or the CLI, and the differences matter more than the presence: on by default in one, off by default in another, preview in a third. A fourth, Cursor, ships it only outside the editor. At the other end, Windsurf's current default agent states plainly that it does not persist memories.
- Disclosure: we build a persistent memory layer, so the last section is the one to weigh hardest. Every fact about every tool is quoted from a page that vendor published, fetched the day this article was checked, and the limit of what such a layer closes is stated as plainly as the gaps in the five.
The four questions, before any tool's name
Comparing "memory" across five products is meaningless until the word is split. Four questions separate cleanly, and the five answer them differently.
- Can you return to the same conversation? Is a resume documented, and what does using it take.
- What degrades even when you do resume? Every tool compacts long sessions. What each keeps is a design choice, and each states it differently, or declines to.
- What survives a brand new session? Not what the agent remembers, but what the tool reloads from disk regardless.
- Is there built-in cross-session memory? Something the agent writes for itself and reads back later, as opposed to a file a person maintains by hand.
Question one: returning to the same conversation
All five ship it, which is why the premise of the question does not survive contact with the documentation.
Claude Code documents five entry points, among them claude --continue for the most recent session in the current directory and claude --resume for a picker, and states what comes back: "A resumed session restores the conversation along with the state saved in it." It also names what does not come back, which is easy to miss: flags such as --mcp-config, --settings or directories added with --add-dir have to be passed again.
Cursor resumes only from its CLI, and documents three ways: "To resume the most recent conversation, use agent resume, --continue, or the /resume slash command", plus agent ls to pick from previous chats.
Codex resumes the last session or a chosen one, with its resume commands marked stable rather than experimental in its own reference.
VS Code needs no flag. Its agent sessions view restores previous sessions in the interface, and the session is the unit that persists.
Windsurf, now Devin Desktop, resumes from its CLI with short flags and from the chat history panel in the desktop app.
The practical consequence is small and useful. If what you lost was the conversation you were just in, you did not lose it; you started a new one instead of reopening that one.
Question two: what degrades even when you resume
Here the five stop agreeing, and a general claim would be wrong for at least three of them.
Claude Code is the only one that documents a choice rather than a silent swap. On Pro and Max plans, resuming a session idle for more than about an hour and over a hundred thousand tokens opens a dialog before your first message with three options: resume from summary, which runs a compaction immediately; resume the full session as is; or stop asking. Its documentation is unusually specific about what a compaction keeps and what it does not: the summary "replaces the verbatim conversation: full tool outputs and intermediate reasoning are gone", while the instruction file, the auto memory and up to five recently modified files are re-read from disk. Its thresholds are stated in tokens, never in percentages.
Codex compacts on command and automatically at a configurable token limit, which is unset by default and falls back to model defaults.
VS Code is explicit about the loss and silent about the trigger: compaction happens when the context window fills up, and "important details from early in a long conversation might be compressed or lost". No percentage appears anywhere in its current pages, and an earlier pair of thresholds that circulated for this tool could not be found in any of them, so they are not repeated here.
Cursor documents that every chat shares a fixed context window and that the agent compacts as it fills, but names neither a threshold nor what specifically is dropped.
Windsurf documents both an automatic background compaction and a forced one, with /compact described as "Force conversation compaction" and nothing said about what a compaction keeps.
Question three: what a brand new session still loads
Every one of the five reloads static instruction files from disk at the start of every session: the ones a person wrote. VS Code calls them always-on instructions, automatically included in every chat request. Cursor reads its own rules format and other tools' files as well. Windsurf's default agent injects rules "into the agent's context at the start of every session".
This is real, and it is why a fresh session still knows your conventions. It is also not memory. An instruction file is a thing a person decided once. Memory is what the agent accumulated from what actually happened, and Claude Code draws the line in its own documentation: instructions you write, versus notes the agent writes itself based on your corrections and preferences.
Question four: built-in cross-session memory
Three of the five ship it in the editor or the CLI, a fourth only for cloud automations, and the differences matter more than the presence.
Claude Code has auto memory, and it is on by default in its own words. It writes four kinds of note for itself, tagged in the file: your role and preferences, corrections you gave it, ongoing project decisions that cannot be derived from the code or git history, and pointers to where information lives outside the project. Each project gets its own memory directory, and it loads at the start of every session alongside the instruction file.
Codex has memories, and they are off until you turn them on: "Local Codex memories are off by default."
VS Code shipped a memory tool, currently in preview, with three scopes stated in a table: user memory persists across sessions and workspaces, repository memory persists across sessions but is workspace scoped, and session memory is cleared when the chat ends. All three are stored locally on your machine. Whether the tool is enabled by default is not stated on that page, only that a setting turns it on or off, so this article does not state it either.
Cursor is the case most easily got wrong, in both directions. Memories exist and are documented, but not for the surface this comparison is about: among the coding surfaces, only cloud automations have them. There they "let the agent read and write persistent notes across runs for the same automation", they are enabled by default, and the documentation carries an honest warning that an automation handling untrusted input can be fed misleading memories that affect later runs. The scope is a single automation. For the editor and the CLI, no memory page exists, and Cursor's own framing puts the persistent layer elsewhere: "Large language models don't retain memory between completions. Rules provide persistent, reusable context at the prompt level." What the editor does have is an @Chats mention, documented as a way "to reference context from a previous conversation", which is a different thing from carrying them forward.
Windsurf is the surprise, and it needs its qualifier every time. Memories belong to the legacy Cascade agent, and the current default agent is not Cascade. In a warning callout at the top of that very page: "Memories apply to the legacy Cascade agent only. The Devin Local agent, the default agent for new tabs, does not persist memories." The same limitation is listed again on the default agent's own page. Cognition rebranded Windsurf as Devin Desktop in June 2026 and made Devin Local the default for new tabs in late July, on 29 July, eight weeks later rather than in one event. Cascade's memory feature remains real and documented. What changed is which agent a new user meets first.
The table
| tool | resume | what compaction drops | loaded in a new session | built-in cross-session memory |
|---|---|---|---|---|
| Claude Code | five documented entry points, transcripts on disk | tool outputs and intermediate reasoning gone; instruction file, auto memory and up to five recent files re-read | instruction files, every session | yes, on by default, four note types, per project |
| Cursor | CLI only: resume, continue, or a session list | mechanism documented, threshold and contents not | rules, AGENTS.md and other tools' files | of its coding surfaces, only cloud automations, on by default there, scoped to one automation |
| Codex | resume last or chosen, marked stable | manual command plus an automatic limit, unset by default | instruction file, rebuilt every launch | yes, off by default, in its own words |
| VS Code | sessions restore in the interface | detail from early in the conversation may be lost, no threshold named | always-on instruction files, automatically | yes, preview, three local scopes, default state not stated |
| Windsurf (Devin Desktop) | CLI flags and a history panel | forced and background compaction, contents not described | rules injected at the start of every session | no, for the current default agent, stated in a warning callout |
Three memories, one company name
One separation is worth making, because it is where most of the confusion arrives from. In late August 2026 Anthropic unified memory between its chat product and Cowork. That announcement is about the assistant applications, and it is precise about defaults: memory is on by default on Free, Pro and Max plans across web, desktop and mobile, saving sensitive topics is off by default, and on Team and Enterprise an admin controls availability while it stays off for individual users until they turn it on.
The body of that announcement does not mention the coding tool or the API at all. So enabling memory in the chat app changes nothing about the agent in your terminal, and the auto memory in the coding tool is a different feature with a different scope. Same company, same word, two mechanisms. Checking which one you turned on takes a minute and saves an argument.
Where a persistent memory layer closes the gap, and where it does not
Resume is a client feature. A memory layer neither replaces nor competes with it: with or without one connected, the resume command behaves the same.
What a layer adds is exactly the gap in question three. A fact written once comes back in any later session, including a brand new one, on another day, and in a different tool entirely, because it lives outside the session rather than inside it.
Two honest limits belong here, stated as plainly as anything above.
The first is that this depends on the agent actually calling the write and the read. A tool being available is not the same as a model choosing to use it, which is why the standing-instruction technique exists at all and why it is documented rather than assumed.
The second is that Claude Code's auto memory is a genuine close relative of the same idea, on by default, and saying otherwise would be false. The difference is scope: that directory is one tool and one project's worth of notes, while a memory layer follows one account across every connected tool. That is a real difference, and it is not a claim that their feature is worse.
A five-minute check on your own setup
Run this before concluding anything about your own tools, because the answers differ per tool and change month to month.
Open the tool you use most and resume yesterday's session rather than starting a new one. Then start a genuinely new session and ask it something only the earlier conversation could answer. If the new session knows it, cross-session memory is on; if it knows your conventions but not the conversation, what you have is the instruction file doing its job. Then check whether your tool's memory feature is enabled, which for two of the five above is not the default and for one is not stated anywhere. Finally, if you work across two tools, ask the second one the same question, because that boundary is the one none of the five crosses on its own.
Related
- Best Persistent Memory APIs Compared: the vendor side of the same question, six memory systems on six criteria
- MCP servers that share state across IDEs: the cross-tool half, and the quiet ways sharing stops
- Claude Code guide: connecting a memory layer to the tool named most often above
Every claim about the five tools is quoted from a page that vendor published, fetched live 2026-09-04 with full browser headers, one research pass per tool. Four of the five moved their documentation domains recently and VS Code moved its paths, so the addresses used here are the current canonical ones: code.claude.com, learn.chatgpt.com, cursor.com/docs, code.visualstudio.com/docs/agents and docs.devin.ai. Three things this article deliberately does not say: that any of the five has no memory, which is false for all of them; that VS Code's memory tool is on or off by default, which its documentation does not state; and that Cursor has no memory feature, which a sweep of all its full documentation index disproves, with the correction that among its coding surfaces the feature covers cloud automations rather than the editor. Disclosure: this site publishes a persistent memory layer, and the section about what such a layer closes names its own limit rather than only the gaps in the five. No performance or benchmark number appears in this article, for any system, pending a completed clean benchmark run of our own.