How to Resume a Claude Code Session (and What Resuming Can't Bring Back)

You spent an hour with Claude Code working through a tricky migration. It knows which approach you rejected and why, which tests are flaky, and what's left to do. Then you close the terminal.

Tomorrow you don't want to explain all of that again. You don't have to: Claude Code saves every conversation and can pick any of them back up. This guide covers how, the habits that make it work well — and the part of "picking up where you left off" that no resume command can restore.

Commands reflect Claude Code as of September 2026. See Anthropic's session docs for the current details.

The two commands you need

claude --continue      # or -c: reopen the most recent conversation in this directory
claude --resume        # or -r: pick from a list of past conversations

--continue is the one you'll use most. Run it from the project directory and you're back in your last conversation, with the full history — every message, every tool call, and every result.

--resume opens a session picker: an interactive list of past conversations for this project, showing each one's name or summary, when it was last active, and its git branch. Arrow keys to move, Space to preview, Enter to resume. Start typing to search.

Inside a running session, /resume does the same thing — it switches to a different conversation without quitting.

Name your sessions

The picker is only useful if you can tell sessions apart. Claude Code generates a title from your first prompt, but "fix the thing" makes for a poor title. Name sessions you'll want to return to:

claude -n auth-refactor          # name it at startup

Or, mid-session, /rename auth-refactor. Then come back to it directly by name:

claude --resume auth-refactor

Named sessions become useful once you're running several pieces of work at once — especially alongside parallel agents in git worktrees, where each worktree has its own conversations.

Branch instead of derailing

Sometimes you want to try a different approach without losing the current one. Rather than steering the existing conversation somewhere risky, branch it:

/branch try-streaming-approach

That copies the conversation so far into a new session and switches you into it. The original stays intact in the picker. From the command line, the equivalent is claude --continue --fork-session.

What a resumed session restores

A resumed session brings back:

The full conversation, including tool calls and their results.
The model it was using, where that model is still available.
The permission mode, when you resume from a terminal with --continue or by exact name or ID — with exceptions for the riskier modes, which you have to opt into again.
Scheduled tasks that haven't expired.

And it deliberately doesn't bring back:

Background commands. A dev server or watch build Claude started in the background isn't running any more.
Some launch flags. If the session depended on --mcp-config, --add-dir, or --settings, pass them again. Settings in your normal settings.json files are re-read automatically.
A tool call that was cut off. If the previous process died mid-command, that command doesn't re-run; Claude continues without its output.

Long sessions: resume from a summary, or in full

If a session is large and has been idle for a while, resuming it has a cost: the whole history is sent to the model again. On Pro and Max plans, when you resume a session that's been inactive for more than about an hour and is over roughly 100,000 tokens, Claude Code asks how you want to continue:

Resume from summary compacts the history into a summary first. Later messages are cheaper, but details the summary leaves out are gone from Claude's context.
Resume full session as-is keeps everything, at a higher cost per message.

Neither is wrong. If the useful context is "what we decided and what's left," a summary is fine. If you need Claude to remember the exact error output from two hours ago, keep it all — or better, get that output into a file.

Sessions are stored locally, per machine

Transcripts live on disk, by default under ~/.claude/projects/, as one file per session. Three consequences:

They're tied to the machine. A session started on your laptop isn't in the picker on your desktop. (Claude Code's desktop app, web version, and VS Code extension also keep their own session histories.)
They expire. Transcripts are cleaned up after 30 days by default; cleanupPeriodDays in settings changes that.
They contain everything. Every file the agent read and every command output is in there. Treat the directory like you'd treat your shell history, or more carefully.

The part resuming can't restore

Here's the limit worth understanding. A resume command restores the conversation. It doesn't restore the world the conversation was about.

Claude's memory of yesterday says the dev server is on port 3000, the test database has seed data in it, node_modules has the dependency you added, and the migration ran. None of that is stored in the transcript. It's stored in your environment — and your environment has had a night to change.

On a laptop, that's usually fine. On anything more ephemeral, it goes wrong in predictable ways:

A fresh container or cloud sandbox. The conversation resumes, but the dependencies aren't installed, the database is empty, and the branch isn't checked out. Claude confidently continues from a state that no longer exists, and its first few commands fail.
A different machine. The session isn't even there to resume.
A server that rebooted. Background processes are gone, and anything written to temporary storage went with them.

The most expensive version is the subtle one: the environment has partly changed, and Claude's assumptions are mostly right. It edits a file that has since been rewritten, or runs a migration against a database that was reset.

We wrote about this distinction at length in Why Your AI Agent Keeps Forgetting: conversation memory and environment state are different problems, and fixing one doesn't fix the other.

Habits that make resuming reliable

Write progress to a file, not just to the conversation. Ask Claude to keep a short NOTES.md or TODO.md up to date: what's done, what's next, what's been ruled out. Files survive compaction, summaries, new sessions, and different machines. Transcripts don't reliably survive all four.
Commit and push at stopping points. Git is the state you can trust. A resumed session that starts with git status and git log -5 re-grounds itself in seconds.
Put durable facts in CLAUDE.md. How to run the tests, which commands are dangerous, how the project is laid out — anything true across every session belongs there, not in one conversation. See How to Write a CLAUDE.md That Actually Helps.
Start a resumed session by checking reality. "Before continuing, check git status, confirm the dev server is running, and verify the last migration applied." It costs one turn and prevents the confident-but-wrong failure.
Know when to start fresh instead. If a conversation has wandered or is full of dead ends, /clear and a two-line summary of the goal often beats resuming. The notes file makes that cheap.

Keeping the environment alive too

Resuming works best when the environment on the other side of the conversation is the one Claude left: same filesystem, same installed dependencies, same database, same branch. On your own machine you get that for free as long as you use the same machine. Anywhere else, it has to be designed in — the workspace has to persist, not be recreated per session.

That's the other half of "pick up where you left off." --continue handles the conversation. Something else has to handle the world.

EasySpawn runs Claude Code in a persistent workspace: source, dependencies, git state, and a managed database survive between sessions, and you reconnect from any device — so when you resume the conversation, the environment it's talking about is still there. See how it works or join the waitlist.