TL;DR
When an agent session ends mid-change, the next one needs the repository's actual state, and a summary can present an old assumption as a current fact. Save a short handoff that keeps durable knowledge, such as instructions and decisions with reasons, apart from current state: branch, last commit, uncommitted files, checks and their results, next step. Record how each claim was verified, and have the new session re-check it against Git and a fresh test run before continuing.
Summaries forget, and project notes go stale
In August 2025 a Cursor user asked on the Cursor forum how to summarize a long chat and continue in a new one. A staff reply suggested referencing the previous chat from the new one; another user replied that in their experience both the automatic summary and the chat reference were poor at remembering what had actually been done.
In July 2026 a backend engineer on a mature multi-service product asked on the OpenAI Developer Community how others preserve project context across Codex sessions. Every new session rediscovered the architecture and earlier decisions, their AGENTS.md did not capture what had been learned during tasks and could go out of date as the project changed, and they asked how to stop outdated context from misleading the agent.
What carries over by itself, and what does not
From the vendors' documentation as of 30 September 2026:
- Claude Code starts every session with a fresh context window;
CLAUDE.mdand its auto memory are what carry across (how Claude remembers your project). When a long session is compacted, its context window page lists what survives: the rootCLAUDE.mdis re-read from disk, the Git status snapshot is re-read fresh, path-scoped rules return only when a matching file is read again, and context that hooks added earlier is summarized away. Resuming an idle session from a summary means, in the words of the sessions page, that "whatever the summary leaves out is no longer in Claude's context" (managing sessions). - Codex builds its instruction chain from
AGENTS.mdat the start of each run, resumes sessions withcodex resume, and replaces earlier turns with a summary when you run/compact(slash commands). Its memories feature is off by default, and its documentation says to treat memories as a recall layer rather than the only place rules live (Codex memories). - Cursor compresses older parts of a conversation into a summary as the window fills (prompting documentation). Its January 2026 best-practices post says context accumulates noise after many summarizations, and recommends starting a new conversation and referencing the old one with
@Chatsrather than pasting it (Cursor blog).
In all three, instruction files persist, the Git state can be re-read, and everything that lived only in the conversation is summarized or gone.
Split the handoff into durable knowledge and current state
Durable knowledge stays true across many sessions: build and test commands, conventions, and decisions with their reasons. Conventions belong in the project's instruction file. Decisions belong in a short log in the repository, one line each with the decision, the reason, the date and who made it, so a later session does not reopen a settled question or quietly reverse it.
Current state is only true now: which branch, what was committed, what is uncommitted or untracked, which checks ran and what they returned, what failed and the next step. It goes in a handoff note written at the end of the session, and every line should say how it is known.
Anthropic's engineering guidance on long-running agents describes the same split: a progress file plus Git history lets a fresh session understand the state of the work, and each session should begin by reading the Git log and progress notes and running a basic test before starting new work (Effective harnesses for long-running agents).
Re-check the state before continuing
A note can be right about what was finished and wrong about what is left. A small repository and a handoff note were written by hand for this article, with one true claim and two stale ones, then checked the way an incoming session should.
One detail from that run matters in practice: git diff --stat listed only the modified file, because git diff does not show untracked files. git stash has the same gap unless you pass -u, so a stash can leave the untracked half of the work behind.
Claude Code applies the same caution to itself: when a resumed session contains a tool call that was cut off, the sessions page says Claude is told to check whether it took effect before running it again. Treat every claim in a handoff the same way.
Keep a summary from turning old assumptions into facts
Most stale handoffs are not wrong when written; they go wrong while nobody is looking.
- Date the note and name its sources. "All tests pass" means little without the command and the time it ran.
- Separate observed from believed. A line copied from command output is evidence; a line from memory is a hypothesis for the next session to check.
- Remove finished and abandoned items. One reply in the OpenAI thread, a community opinion rather than documentation, argued that raw session summaries decay into a second, less reliable version of the codebase that keeps dead ends. Keep only what the next session needs.
- Prefer a fresh session over repeated compaction. Anthropic's prompting guide suggests starting a new context window that rediscovers state from the filesystem, and Cursor's post recommends a new conversation after a logical unit of work.
If you use the tools' own resume features, they restore the conversation, not the world. Claude Code's checkpoints do not track files changed by shell commands and are not a replacement for Git, so a resumed conversation can believe in edits that were later undone, or miss edits made outside it.
Make the handoff reconstructable for another engineer
If the resumed work later fails, someone has to work out what the previous session knew. That is much easier when the note is backed by small commits with descriptive messages, when decisions live in the repository rather than in a chat, and when the note names the commits it describes.
Paqad records this per change: each change has an evidence bundle with its plan, a specification where the lane requires one, checks and the decisions a person resolved, and work that pauses for a decision resumes only once the resolved answer exists on disk. Its session-start logic also tries to reconnect unfinished work on the current branch after a restart; that reconnection is best-effort recovery, not a guarantee. None of it replaces the check above; it gives the check more to compare against. If you would rather have that evidence kept for every change than written by hand, Paqad's session handoff documentation describes the records it keeps.
A load record belongs to one session, so the new session has to load the project instructions again; the article on checking that an agent loaded the project instructions shows how to confirm it did. To keep that session's context small without dropping a rule it needs, see how to reduce an agent's context without hiding what it needs.
Frequently Asked Questions
What should I save so a new AI coding session can continue the work accurately?
Whatever the next session cannot re-derive from the repository: decisions and their reasons, work deliberately left undone, and how each state claim was verified. Branch, commits and changed files can be re-read with Git, so the note only needs to point at them.
Which decisions, unfinished edits and failed checks are essential to the next session?
Decisions that constrain the next step, so they are not reopened or reversed; every untracked file, because git diff will not show it; and each failing check with its exact command and test names, so the next session reruns the same thing rather than a broader or narrower suite.
How do I keep a summary from presenting stale assumptions as current facts?
Give every state line a source and a time, and write the next session's first instruction as "re-check these claims" rather than "continue". A claim without a command behind it is a hypothesis, however confident it sounds.
What should the incoming session recheck against Git and the running environment before continuing?
Beyond the three commands above, anything outside the repository the work depends on: running services, environment variables, database migrations already applied, and any branch it was meant to rebase on. A resumed conversation restores messages, not processes.
How can another engineer reconstruct the handoff if the resumed work later fails?
Commit the note next to the code, name the commits it describes and keep the decisions log in the repository. Another engineer can then compare what the previous session believed with what the commits and test history show, without the original conversation.