Quick answer: To resume a Claude Code session, run claude --continue (or clause -c) in the project directory to reload your most recent conversation, or run claude --resume (or claude -r) to open an interactive picker and choose a specific past session. From inside an active session, type /resume to switch conversations without restarting Claude Code.
Claude Code saves every conversation to a local transcript file as you work, so closing the terminal, running /clear, or restarting your machine doesn't erase your project history. The trick is knowing which resume command fits your situation and understanding what actually comes back with the session (and what doesn't).
This guide covers every resume path in the CLI, what gets restored, why a session might not show up in the picker, and how to pull session data into scripts.
The Fastest Way to Resume: claude --continue
If you just closed Claude Code and want to pick up exactly where you left off, in the same directory, this is the command:
bash
claude --continue
Or the shorthand:
bash
claude -c
This resumes the most recent interactive session tied to your current working directory. There's no ID to copy, no picker to navigate — Claude Code finds the last conversation for that folder and reloads it, including tool calls, file edits, and prior messages.
You can also pass a follow-up prompt directly:
bash
claude -c "check if the tests pass now"
What --continue does not pick up: sessions started with claude -p (headless/scripted runs), Agent SDK sessions, background sessions, and any session whose very first prompt was a /loop command. If your last work happened through one of those paths, --continue will look right past it — see the sections below for how to resume those instead.
Resuming a Specific Session with claude --resume
When you have more than one conversation going for a project — say, one thread debugging auth and another refactoring the API layer — --continue isn't precise enough. Use --resume instead.
Open the interactive session picker
bash
claude --resume
or the shorthand claude -r. This opens a list of saved sessions for the current project (and, by default, sessions from other directories that were added to this one with /add-dir).
Inside the picker:
Shortcut | Action |
|---|---|
↑ / ↓ | Move between sessions |
Enter | Resume the highlighted session |
Space | Preview session content |
Ctrl+R | Rename the highlighted session |
Ctrl+A | Show sessions from every project on the machine |
Ctrl+W | Show sessions from all worktrees of the current repo |
Ctrl+B | Filter to the current git branch |
/ or any letter | Start searching/filtering |
Esc | Exit the picker |
Each row shows the session's name (if you set one), an AI-generated title based on the first prompt, how long ago it was active, the git branch, and file size.
Resume by session ID or name directly
If you already know the session's ID or the name you gave it, skip the picker entirely:
bash
claude --resume <session-id> claude --resume auth-refactor claude -r "abc123" "Finish this PR"
An exact name match resumes immediately. An ambiguous or partial name reopens the picker with that text pre-filled as a search term.
Tip: Add --fork-session to any resume command to branch into a new session ID instead of writing further messages back into the original transcript for example, claude --resume abc123 --fork-session. Useful when you want to explore a different approach from an old conversation without altering it.
You can run claude --resume <session-id> from any directory Claude Code checks the current project and its git worktrees first, then searches every other project on the machine, and resumes the match if exactly one other project has a transcript for that ID.
Resuming from Inside a Running Session
You don't have to quit Claude Code to switch conversations. From an active session, run:
/resume
This opens the same picker described above, without leaving your terminal. It's the fastest way to bounce between two parallel tasks in the same project.
Resuming a Session Linked to a Pull Request
If a session was tied to work on a specific PR, you can jump straight to it:
bash
claude --from-pr 123
This opens the session picker filtered to conversations linked to that pull request number.
Naming Sessions So You Can Find Them Later
Resuming by ID works, but IDs aren't memorable. Naming a session up front makes --resume <name> far more useful once you're juggling several conversations:
| When | How |
|---|---|
| At startup | claude -n auth-refactor |
| Mid-session | /rename auth-refactor |
| From the picker | Highlight a session, press Ctrl+R |
If you don't name a session, Claude Code still generates a short title from your first prompt (via a fast background model), and you can use that generated title as a resume handle too.
What Actually Comes Back When You Resume
A resumed session restores:
Full conversation history every message, tool call, and result.
The model it was running on, unless that model has since been retired, isn't allowed by your availableModels setting, or you launch with an explicit --model flag.
The agent, if the session was started with --agent including its system prompt and tool restrictions.
Permission mode, in most terminal-based resumes (--continue, --resume <id>, --resume <name> with an exact match) with exceptions for bypassPermissions and plan mode, which fall back to whatever mode a new session would start in unless you pass --permission-mode again.
An active goal, if one was running when the session ended (its turn count and timer reset).
Scheduled tasks that haven't expired.
What is not automatically restored: flags like --mcp-config, --settings, --plugin-dir, --fallback-model, and directories added via --add-dir at launch. If your original session depended on any of these, pass them again when you resume. Standard settings files (settings.json, settings.local.json) are re-read automatically, so you don't need to repeat anything stored there.
The "resume from summary" prompt on long sessions
On Pro or Max plans, if you resume a session that's been inactive for roughly an hour or more and has grown past about 100,000 tokens, Claude Code shows a dialog before your first message goes through, since the prompt cache has already expired:
Resume from summary runs /compact immediately, replacing history with a summary plus your most recent exchanges.
Resume full session as-is keeps everything, at a higher per-request token cost going forward.
Don't ask me again to resume full sessions from now on without prompting.
If you need every detail preserved (exact error messages, prior tool outputs), choose "as-is." If the session is mostly settled and you just need continuity, the summary option is cheaper per request.
Troubleshooting: Session Won't Resume
You're in the wrong directory
This is, by far, the most common reason --continue or --resume comes up empty. Sessions are scoped to the project directory they were created in, so running claude --continue from ~/ when the session actually ran in ~/git/myproject will report nothing found. Fix: cd into the exact folder the session ran in, then retry.
If you're not sure which folder that was, you can find it by browsing the transcript storage directly:
bash
# List every project that has saved sessions ls ~/.claude/projects/ # List sessions for one project, newest last ls -lt ~/.claude/projects/-Users-you-git-myproject/
Folder names are your project's full path with slashes replaced by hyphens (on Windows, the base is %USERPROFILE%\.claude\projects\). The folder name tells you exactly which directory to cd into.
"No conversation found with session ID: <session-id>"
This means Claude Code searched the current project, its worktrees, and every other project on the machine, and found no transcript matching that ID — or found more than one copy, which it treats as ambiguous rather than guessing. Double-check the ID for typos, and confirm you're not resuming a session that was manually copied between machines.
A session doesn't appear in --resume or --continue
Check whether it falls into one of these excluded categories:
- Created with claude -p or the Agent SDK — these are intentionally left out of the interactive picker and out of --continue. Resume them with claude --resume <session-id> (the ID still works even though the session doesn't show in the list), or use the headless flow below.
- A background session — skipped by --continue; visible in the picker marked bg.
- First prompt was /loop — these are hidden from the picker entirely, and --continue skips them too.
- Started in a different worktree or unrelated project — press Ctrl+W (worktrees) or Ctrl+A (all projects) inside the picker to widen the search.
Picker shows the session but resuming fails
If Claude Code can't load the transcript you selected, it prints Failed to resume the conversation along with a retry command, then exits. From /resume inside an existing session, the failure is reported without ending your current conversation. This usually points to a corrupted or partially written transcript file rather than something you did wrong.
Resuming from another machine or a moved project
Session transcripts live locally at ~/.claude/projects/<project>/<session-id>.jsonl, where <project> is your working directory path with non-alphanumeric characters replaced by hyphens. If you moved the project folder or switched machines without copying ~/.claude, the old sessions won't be there to resume. Moving a session with /cd relocates its storage to the new directory going forward. There's no built-in cloud sync for CLI transcripts — the supported path is resuming on the machine (or copied ~/.claude directory) where the session actually ran.
A session dropped over SSH, or after your laptop slept
If a session runs over SSH and the connection drops, the transcript on disk is untouched — closing the connection is just closing the view, the same as closing a terminal tab. But if you want the running process itself (not just the conversation) to survive a dropped connection, start Claude Code inside tmux or screen on the remote box first. A dropped SSH connection then only detaches the terminal multiplexer; reattach with tmux attach and Claude Code is still running mid-task, no resume needed at all.
A very large session refuses to load ("Prompt is too long")
Sessions that have grown very large can fail to resume with an invalid_request / "Prompt is too long" error, because the full history has to be reprocessed before any compaction can run — there's no supported way to force compaction before loading. Try --continue first, which triggers the "resume from summary" dialog before full reprocessing if the session qualifies (see above); otherwise start fresh and pull what you need from the old transcript manually — it's still readable as plain JSONL even if Claude Code can't reopen it.
--continue doesn't find a session you just resumed with --resume
On some versions, resuming through the picker doesn't update the "most recent conversation" pointer --continue relies on, so a follow-up --continue starts a new session instead of returning to the one you just picked. If this happens, resume by name or session ID directly instead, and check claude --version — state-tracking bugs like this tend to get patched quickly.
Sessions "teleported" from Claude Code on the web don't show in the picker
Handing a session off from Claude Code on the web to the local CLI can leave it missing from the --resume / /resume picker even though its transcript exists on disk — a picker-indexing gap, not lost data. Look it up manually (ls ~/.claude/projects/<project>/) and resume by session ID.
Auto-resuming after you hit a usage limit
The standard recovery from a usage-limit pause is still claude --resume or -c once it resets. If you don't want to babysit the countdown, community wrappers exist that watch for the reset and auto-continue — search "claude auto resume" on GitHub. Treat any such script with normal caution, especially if it pairs auto-resume with --dangerously-skip-permissions.
VS Code extension and desktop app don't match the CLI
The CLI's --continue / --resume / /resume set is the most complete resume toolkit Claude Code offers. The VS Code extension and desktop app keep their own, currently more limited, session history and resume UI — don't assume a session started in one surface is one click away in another.
Resuming Sessions in Scripts and Headless Mode
For automation, claude -p supports the same resume logic, with the reverse exclusion rule: claude -p --continue and claude -p --resume include -p, SDK, and /loop sessions (they still skip background sessions).
Send a follow-up prompt to a specific session and capture structured output:
bash
claude -p --resume <session-id> --output-format json "summarize what we changed" | jq -r '.result'
Continue the most recent conversation non-interactively:
bash
claude -p --continue "run the test suite and report failures"
This is the pattern to use if you're building a script or CI step that needs to follow up on a prior Claude Code run rather than starting cold.
Branching Instead of Overwriting a Session
If you want to try a different approach without losing your current path, branch instead of resuming in place:
/branch try-streaming-approach
Or from the command line:
bash
claude --continue --fork-session
Branching copies the conversation so far into a new session ID and switches you into it; the original stays untouched and remains resumable with /resume <original-name>.
Common Mistakes to Avoid
- Expecting --continue to find claude -p sessions. It won't — use --resume <session-id> or the headless resume flow instead.
- Assuming a session survived a machine switch. Transcripts are local files under ~/.claude/projects/; without copying that directory, there's nothing to resume.
- Resuming a long-idle session and being surprised by cost. Choosing "resume full session as-is" on a large, stale session reprocesses the entire history on your next message — that's expected, not a bug.
- Losing track of which permission mode you're in after resuming from the picker. Picker-based resumes (and /resume) don't restore the original permission mode — they start you in whatever mode a new session would use. Pass --permission-mode explicitly if you need a specific one.
FAQ
--continue (-c) always loads the single most recent interactive session in the current directory with no picker involved. --resume (-r) either opens an interactive picker or jumps directly to a session if you give it an ID or exact name — and it can reach sessions --continue skips, if you know the ID.
It depends on how you resume. Resuming with --continue or by exact ID/name from the terminal restores the original mode in most cases. Resuming via the session picker, /resume, or claude -p does not restore the stored mode — it starts you in whatever mode a fresh session would use instead.
No. /clear starts a new, empty conversation but keeps the previous one saved. Bring it back with /resume.
By default, transcripts are retained for 30 days, controlled by the cleanupPeriodDays setting in settings.json.
Yes — claude --from-pr <number> opens the picker filtered to sessions linked to that PR.
~/.claude/projects/<project>/<session-id>.jsonl by default, where <project> is a sanitized version of your working directory path. The format is internal and can change between versions, so use /export or the documented script interfaces (claude -p --output-format json, hook transcript_path, or the Agent SDK) rather than parsing these files directly.
Conclusion
For most day-to-day work, Claude --continue gets you back into your last conversation with zero friction. Reach for claude --resume — or /resume from inside a session — when you're juggling multiple threads on the same project and need to pick a specific one. Keep in mind the categories of sessions that fall outside the default picker (claude -p, Agent SDK, background, and /loop-first sessions), since those need an explicit session ID or the headless resume flow instead. Once you know which command matches your situation, you should never have to re-explain a debugging session from scratch again.