Claude Code session state: resume and rewind

People sometimes loosely call this "run state": the stuff Claude Code is holding while it works for you. The instinct is right but the term is fuzzy, because no single thing has that name. What exists is three separate kinds of state, each living for a different length of time and each recovered in a different way. Confuse them and you reach for the wrong tool: you resume a session expecting your files back, or you rewind a file expecting your conversation back.

This guide untangles the three. It is about what a run keeps while it runs, what survives when the run ends, and the two recovery moves, resume and rewind, that put you back where you want to be.

The three kinds of state

Hold these apart and almost everything else follows.

Durable memory is your project memoryA file like CLAUDE.md that Claude Code reads at the start of every session and loads as standing instructions: a CLAUDE.md and any auto-saved notes. It is loaded fresh at the start of every session, so it survives clearing, resuming, and restarting. For how that layer works, see how Claude Code memory works.

Session state is the live conversation of one run: your prompts, every tool call, every result, every reply. It is the volatile working layer this guide focuses on.

Files on disk are the edits the agent made. The moment Claude Code saves a file, that change is real and on your filesystem. It is not waiting in some buffer to be committed by the session.

The live context window

While a run is happening, the agent's working state lives in the context windowThe fixed amount of text the model can read in one turn: your prompt, the conversation so far, and tool results. This is everything it can currently see: your instructions, the conversation up to now, the files it has read, and the output of the tools it ran. When the agent decides what to do next, it decides from the contents of that window and nothing else.

That has a sharp consequence. Clear the window and the working state is gone. The agent no longer knows which files it read or what it concluded ten steps ago, because those facts only lived in the window. What does not vanish is anything that was written down somewhere durable: your CLAUDE.md reloads, and every file the agent edited is still sitting on disk exactly as it left it.

So the window is the most powerful and the most fragile layer. It is where the agent thinks, and it is the one thing a single command can wipe.

How do I resume a Claude Code session?

Here is the relief: clearing the window does not throw the conversation away. Claude Code saves each session's conversation to disk as you go. A session is the full record of one run, and you can reload it later to put that conversation back into a fresh window.

There are three ways back in, depending on how precisely you need to aim.

claude --continue is the everyday move: you closed the terminal, you come back tomorrow, you reopen exactly where you were. /resume (or claude --resume with no id) gives you a picker when you are not sure which session you want. claude --resume <id> is for when you have the id and want that one precisely.

You can also copy a session into a new one instead of continuing it in place, which is handy when you want to try a different direction without disturbing the original thread. The /branch command does this from inside a session, and claude --continue --fork-session (or claude --resume <id> --fork-session) does it from the command line. Either way, forking starts a fresh session seeded with the old conversation, so the original stays intact as a fallback. One thing not to assume: permissions you approved for the original session do not carry into the fork, so the new branch may ask again.

How do I find the session I want?

claude --resume <id> assumes you have an id, which raises a fair question: where does it come from. You rarely need to memorise one. The picker, opened with /resume or with claude --resume and no id, lists recent sessions for the current directory with enough context to recognise them, and you select the one you want. Sessions are scoped to the directory they ran in, so the picker only shows work from this project, not every conversation you have ever had. Reach for an explicit id only when you have captured it deliberately, for example to hand a teammate or a script the exact session to reopen. For everyday "carry on from yesterday," claude --continue skips the choosing entirely.

Does resuming a session restore my files?

No. Resuming a session restores the conversation, not your filesystem. This is the distinction that bites people, so it is worth stating bluntly.Common gotchaThe classic mistake is resuming a session to "get back" a file you have since changed, expecting the old version to return with the conversation.It does not: resume only reloads the talk, and your edits were written to disk the instant they happened. To move files back, rewind within the session or check out the version from git.

When you resume, the agent gets back the memory of what it did. It remembers reading those files, making those edits, reaching those conclusions. What it does not do is roll your files back to how they were at that point. Why would it? Those edits were already written to disk the moment they happened. Resuming does not undo them, and it does not snapshot them either.

So if you edited ten files in a session, walked away, and resumed it, all ten edits are still there. The session handed you back the agent's memory of doing the work, sitting on top of a filesystem that already has the work in it. State and files are two different things on two different timelines. Resume governs state. To move the files, you need a different tool.

How do I undo a bad edit in Claude Code?

That different tool is rewind. Claude Code snapshots file contents as it edits during a session, so it can put your files back to an earlier point in the run. This is the move for "that last change made things worse, take it back."

You trigger it by pressing Esc twice when the prompt input is empty, or with the /rewind command. You pick a point earlier in the session, and Claude Code restores the files to how they were then. One caveat worth knowing: rewind tracks edits Claude made through its own editing tools, not changes a raw shell command made, so a file you moved or deleted with a bash command will not come back this way.Common gotchaDo not lean on rewind to undo a destructive shell step like rm or mv.Those edits sit outside Claude Code's snapshots, so a committed git state is your only way back.

Two things to keep straight about rewind. It is local to the session, not git: these snapshots are Claude Code's own, separate from your version control, so do not expect them to show up in git log. And it acts on files, which is the mirror image of resume. Resume gives you the conversation without touching files; rewind moves the files within the run you are already in.

Two walkthroughs

Recover from a bad edit

You asked for a refactor, the agent made several edits, and a few of them broke things. You want the working version back without unpicking each change by hand.

1. Press Esc twice, or run /rewind.
2. Pick the point just before the bad edits.
3. Claude Code restores the files to that point.
4. Tell the agent what to do differently, then go again.

You are still in the same session, so the conversation is intact. Only the files moved.

Pick up where you left off

You stopped mid-task yesterday. Today you want to continue the same thread, with the agent still aware of the files it read and the plan it formed.

1. From the project directory, run claude --continue.
2. The most recent conversation reloads into a fresh window.
3. Remember: your files are exactly as you left them. The session brings back the talk, not a file snapshot.
4. Carry on, or ask the agent to re-state the plan so you are both aligned.

If you are not sure which session it was, run /resume and pick it from the list instead.

What resets and what persists

It helps to know exactly what each action touches, so you reach for the right one without second-guessing.

/clear wipes the current run's conversation to give you a clean window, but it keeps your durable memory and leaves every edited file in place. It is for "new task, same project," not for undoing work.

Auto-compaction is the one that happens without you asking. On a long run the window fills up, and Claude Code summarises older context, trimming detail from earlier tool outputs to make room. The conversation continues, but fine detail from early on can be lost. Your memory file and your files on disk are untouched by this; only the live window is compressed.

Should I resume a session or start clean?

Resuming is not always the right call. Continue a session when you need the thread: the agent built up context about a tricky task and losing that would mean re-deriving it. Start clean with /clear or a new session when the next task is unrelated, or when the old conversation has drifted, filled with dead ends, or been compacted so heavily that it is more noise than signal. A long, muddy context can make the agent worse, not better. A fresh window plus a one-line summary of where things stand often beats dragging a bloated session forward.

Should I rewind or use git?

Rewind and git overlap, but they are not the same tool, and picking wrong wastes time.

• Reach for rewind when the mess is recent and inside the current session: the last few edits went sideways and you want them gone fast, without leaving the agent.
• Reach for git for anything durable or shared: comparing against a committed state, recovering work from a different session, undoing across commits, or anything a teammate also needs to see.

The rule of thumb: rewind is a quick local undo for the run you are in, git is your real safety net. Rewind does not replace committing. Commit at sensible points and you always have a floor that does not depend on the session, no matter what happens to the window.

Why long runs want a plan file on disk

Put the last two ideas together, volatility plus auto-compaction, and a clear habit drops out: for a long task, do not trust the live window to hold your plan.

The window is the volatile layer. Auto-compaction can trim the early detail of a long run, and a /clear or a crash wipes it entirely. So the very thing you most want to keep on a multi-step job, the plan and what you have learned, is sitting in the most fragile place. Move it somewhere durable.

The fix is a scratch plan file on disk that the agent maintains as it works. A plain markdown checklist does the job: the agent writes the plan, checks items off, and records what it discovers. If the window gets compacted or you resume tomorrow, the plan on disk is still the source of truth, and the agent re-reads it instead of re-deriving it.

This is the same logic that powers durable agent memory in general. For carrying knowledge across steps and runs when you are building agents, see give your agent memory. For deciding what belongs in the window in the first place, see context engineering.

A worked timeline

It is easiest to feel the state-vs-files split by tracing one short story through it.

You start a session and ask the agent to add a feature. It reads three files, edits two of them, and runs the tests. Right now, three things are true at once. The conversation (what was asked, what was read, what was edited) is in the live window. The two edits are already saved on disk. And your CLAUDE.md is loaded, as it has been since the session opened.

Now you close the terminal for the night. The live window is gone, but nothing was lost: the conversation was saved to disk as a session, the two edited files are still on disk, and your memory file is just a file like any other.

The next morning you run claude --continue. The conversation reloads into a fresh window. The agent remembers reading those three files and making those two edits. Crucially, it does not re-apply them or roll them back: the edits were never undone, so the filesystem already matches what the conversation says happened.

Then you notice one of yesterday's edits was wrong. You press Esc twice and rewind to the point just before that edit. Now the files move back, but the conversation stays. You are in the same resumed session, with the same memory, sitting on top of files that have been rolled back one step. From here you redirect the agent and continue.

Every move in that story is one of the three states changing on its own timeline. That is the whole mental model in motion.

Which command do I want?

When something goes sideways, name what you want to recover and the right command follows.

The trap is treating these as interchangeable. Resume and clear act on the conversation. Rewind and git act on files. Pick the row by the noun you care about, conversation or files, and the column falls out.

The whole picture

Three kinds of state, two recovery moves. Durable memory survives everything and reloads on its own. Session state is the live conversation: volatile in the window, but saved to disk and brought back with --continue, --resume, or /resume. Files on disk are already permanent, rewound within a session or managed with git.

The single distinction worth carrying away: resume restores what was said, rewind restores what was written. Keep those two straight, commit at sensible points, and keep your plan in a file on a long run, and a wiped window or a bad edit stops being a setback. It becomes a recovery you already know how to make.