How to Resume a Claude Code Session: --continue vs --resume, Naming Sessions, the Session Picker, Branching, and What Comes Back

You closed the terminal. Or the laptop went to sleep, or you ran /clear a little too eagerly, or you have three Claude Code sessions open on three branches and no idea which one was fixing the auth bug. Every one of those situations has the same answer: Claude Code saves every conversation to disk as you work, and there are four ways to get back into one. This post covers claude --continue, claude --resume, the session picker and /resume, plus the two habits that make resuming painless: naming sessions and branching them instead of overwriting them. Everything here is taken from the official sessions and CLI reference pages, with version notes where behaviour changed recently.

The four ways back in

A session is a saved conversation tied to a project directory. The entry points, from fastest to most flexible:

• claude --continue (or claude -c) reopens the most recent conversation in the current directory. No picker, no questions. If the most recent conversation is a background session that is still running, it refuses and prints the session ID instead.
• claude --resume <name-or-id> (or claude -r) resumes a specific session by the name you gave it, by its UUID, or by the absolute path of its .jsonl transcript. Since v2.1.223, an ID is searched across every project on the machine, not just the current directory, so you can resume from anywhere.
• claude --resume with no argument opens the interactive session picker. claude --from-pr 123 opens the same picker filtered to sessions linked to that pull request; sessions are linked automatically when Claude creates the PR.
• /resume inside a running session switches to a different conversation without leaving Claude Code. /resume <name> goes straight there; /resume alone opens the picker. /continue is an alias.

Two things are deliberately left out of --continue and the picker: sessions created with claude -p or the Agent SDK, and sessions whose first prompt was /loop. You can still resume those by passing their session ID to --resume, and claude -p --continue does include them.

Name your sessions, then resume by name

The single biggest improvement to resuming is to stop relying on the AI-generated titles and name sessions yourself. There are several routes to the same result:

# at startup
claude -n auth-refactor        # same as --name

# mid-session
/rename auth-refactor          # also shows the name on the prompt bar

# from the picker: highlight a session and press Ctrl+R

# later, from any terminal in the repo
claude --resume auth-refactor
# or inside a session
/resume auth-refactor

Name resolution works across the current repository and all of its git worktrees, so a session you started in a worktree is reachable from the main checkout. If the name is ambiguous, claude --resume opens the picker with the name pre-filled as a search term, while /resume <name> reports an error and asks you to use the picker. Since v2.1.232, if another live session already has the name you pick, Claude Code keeps the name on the existing session and gives yours a two-word suffix such as auth-refactor-graceful-unicorn, and tells you; run /rename again if you would rather choose.

Sessions you never name still get two labels. The default display name, working-directory plus a two-character suffix like my-app-3f, identifies the session in listings of running sessions but is not a resume handle. The generated title, a one-line summary of your first prompt written by a small model, is one: you can pass it to --resume or /resume. Accepting a plan in plan mode replaces that title with one based on the plan. In practice, naming the session the moment you know what it is for saves you from ever reading those titles.

Driving the session picker

The picker is more capable than it looks. By default it shows sessions from the current worktree, including background sessions marked bg, and sessions started elsewhere that added this directory with /add-dir. The shortcuts worth memorising:

• ↑/↓ or k/j to move, Enter to resume, 1 to 9 to jump to a position.
• Space previews the conversation before you commit to it.
• Any printable character starts a search. Paste a GitHub, GitLab or Bitbucket PR URL to find the session that created it.
• Ctrl+W widens to every worktree of the repository, Ctrl+A to every project on the machine, Ctrl+B filters to the current git branch. Each toggles back on a second press.
• Ctrl+R renames the highlighted session in place.

Selecting a session from another worktree of the same repository resumes it in place. Selecting one from an unrelated project copies a cd-and-resume command to your clipboard instead, unless that project's directory no longer exists, in which case Claude Code resumes it where you are.

What a resumed session actually restores

Resuming loads the full conversation history, tool calls and results included, and the session continues on the model it was using unless that model has been retired or you override it with --model. A session started with --agent keeps that agent. The permission mode is restored when you resume from a terminal with --continue, --resume <id> or an unambiguous name, with exceptions: a session that ended in bypassPermissions does not come back in it, and one that ended in plan mode comes back in plan mode. Pass --permission-mode to override whatever would be restored.

Two caveats keep catching people. First, a tool that was still running when the previous process died does not finish or re-run; Claude sees it marked as cut off and is told to check whether it took effect. Second, launch flags such as --mcp-config, --settings, --plugin-dir, --fallback-model and --add-dir are not restored, so pass them again. Settings that live in settings.json are re-read at launch and need nothing. If you keep environment variables in a settings file, the environment variables guide covers which ones belong there.

Resume from a summary, or in full

On Pro and Max plans, resuming a session that has been idle for more than about an hour and is over 100,000 tokens opens a dialog before your first message. The prompt cache has expired by then, so the next request pays for the full history once whatever you choose. Resume from summary runs /compact immediately and carries the summary forward; later requests are cheaper but anything the summary dropped is gone. Resume full session as-is keeps every detail at a per-request cost that scales with size. A third option stops the dialog appearing again. For a session you are about to finish, the summary is usually right; for one where you are debugging something subtle, keep it whole. The context management post goes into when to clear versus compact in general.

Branch instead of overwrite

If you resume the same session in two terminals, messages from both interleave into one transcript. The clean alternative is a branch: a copy of the conversation so far that you switch into, leaving the original intact.

# inside a session
/branch try-streaming-approach

# from the shell
claude --continue --fork-session
claude --resume auth-refactor --fork-session

/branch copies the transcript and points the running process at the copy, so "allow for this session" permission grants carry over and in-flight background subagents keep running, with their output landing in the branch. --fork-session starts a separate process, so you re-approve there. The confirmation prints both session IDs; the original stays in the picker. For rewinding within one session rather than branching it, the checkpoints and rewind guide is the companion to this one.

Resuming a background session

Background sessions complicate the picture slightly. claude --continue opens a background session that has finished (v2.1.257 or later) but not one that is still running. Since v2.1.285, resuming a running background session with --resume or /resume opens that session in your terminal, effectively running claude attach; a prompt on the command line is sent as its next turn first. Add --fork-session to work on a copy instead, or claude stop <id> first if you want to continue the original with your own flags. The background tasks post covers that side of the workflow.

Where the transcripts live, and for how long

Transcripts are JSONL files at ~/.claude/projects/<project>/<session-id>.jsonl, where the project directory name is your working directory path with non-alphanumeric characters replaced by -. They are kept for 30 days by default; cleanupPeriodDays in settings.json changes that, CLAUDE_CONFIG_DIR moves the whole store, and claude purge deletes a project's transcripts on demand. The file format is internal and changes between releases, so do not parse it in scripts; /export gives you a readable transcript, and claude -p --resume <id> --output-format json lets a script ask an existing session a question and parse the answer.

A resume-friendly routine

1. Start every real piece of work with claude -n <task>, or /rename it within the first minute.
2. When you need to try something risky, /branch rather than pressing on and hoping.
3. End a session with /clear <name> if you want to label the conversation you are leaving.
4. Come back with claude --resume <name>; reach for the picker only when you have forgotten the name, and use Ctrl+A there before concluding a session is lost.

The one thing none of this solves is knowing when to come back. A resumed session sits idle as happily as a fresh one, and a long task you kicked off before stepping away finishes without telling you. That is the gap a done-notification fills, and it pairs naturally with named sessions: the alert tells you which one is waiting.