To resume a Claude Code session, run claude --continue in the same project folder to reopen the most recent conversation, or claude --resume to choose one from a picker. Inside a running session, /resume switches to another conversation without quitting.
Those three commands cover most days. The rest of this guide explains what a resumed session brings back, how to name and branch sessions so you can find them again, and where Claude Code keeps transcripts on disk. Everything here comes from the official Manage sessions page, checked on 24 October 2026, and covers the CLI. The desktop app, claude.ai/code and the VS Code extension each keep their own session list.
What is a Claude Code session?
The docs define a session as "a saved conversation tied to a project directory." Claude Code writes it to a local transcript file continuously while you work, so a session survives quitting the terminal, a crash or running /clear. That is what makes resuming possible: there is always a file to load.
Because sessions are stored per project directory, the folder you start claude in matters. claude --continue only looks at the current directory, and the picker starts with sessions from the current worktree.
Which command resumes a Claude Code session?
The CLI reference and the sessions page list these entry points:
| Command | What it does |
|---|---|
claude --continue or claude -c |
Reopens the most recent session in the current directory |
claude --resume or claude -r |
Opens the session picker |
claude --resume <name> |
Resumes the named session directly |
claude --resume <session-id> |
Resumes by ID, searching this project first, then every other project on the machine |
claude --resume <transcript-path> |
Resumes from a .jsonl transcript file at that absolute path |
claude --from-pr <number> |
Opens the picker filtered to sessions linked to that pull request |
/resume |
Switches to another session from inside an active one |
--from-pr also accepts a GitHub, GitHub Enterprise, GitLab or Bitbucket pull or merge request URL. Sessions get linked automatically when Claude creates the pull request.
Some sessions are hidden by default. Runs started with claude -p or the Agent SDK, and sessions whose first prompt was /loop, stay out of the picker and out of claude --continue. You can still open one by passing its session ID to claude --resume, and claude -p --continue does include them. See the headless mode guide for scripted runs.
What does a resumed session restore?
When Claude Code loads a conversation from its transcript, it brings back more than the messages:
- Conversation history: messages, tool calls and results. If the session was compacted, Claude continues from the last compaction summary plus everything after it.
- Model: the session continues on the model it was using, with a few documented exceptions.
- Agent: a session started with
--agentcontinues as that agent, with its tool limits and model. - Permission mode: resuming from a terminal with
claude --continueor a specific ID or unique name restores the mode the session was in, with exceptions. A session that ended in bypass permissions mode does not come back in that mode, and auto mode returns only if your account still qualifies. - Active goal and scheduled tasks: an active goal carries over, and session-scoped scheduled tasks that have not expired are restored.
- Interrupted tool calls: a tool that was still running when the old process ended is not rerun. Claude is told it was cut off and to check whether it took effect first.
Some launch flags are not restored. If the session depended on --mcp-config, --settings, --plugin-dir, --fallback-model or --add-dir, pass them again. Settings files such as settings.json are re-read at launch, so anything stored there needs no extra step.
One cost detail is worth knowing. Resuming a long conversation after a break means the model reprocesses the whole history, because the cache has expired. On Pro and Max plans, a "Resume this conversation?" dialog can appear in that case, estimating the share of your 5-hour usage limit the saved conversation alone would use. The prompt caching guide explains why.
How do you name Claude Code sessions so they are easy to find?
Named sessions are much easier to resume, especially when you run several tasks in parallel. You can set a name in several places:
| When | How |
|---|---|
| At startup | claude -n auth-refactor |
| During a session | /rename auth-refactor (the name also shows on the prompt bar) |
| In the session picker | Highlight a session and press Ctrl+R |
| On plan accept | Accepting a plan in plan mode generates a title from the plan, unless you already named the session |
Once named, return with claude --resume auth-refactor or /resume auth-refactor. An exact match resumes directly, even from a different worktree. An ambiguous name opens the picker pre-filled when you use claude --resume, but reports an error with /resume.
Unnamed sessions get two automatic labels. A display name like my-app-3f identifies running sessions in listings, but it is not a resume handle. A generated title, a short summary of your first prompt written by a small fast model, does work with --resume.
How do you use the session picker?
Run claude --resume with no argument, or /resume inside a session, to open the picker. Each row shows the session name or generated title, time since last activity, git branch and file size. The useful keys:
| Key | Action |
|---|---|
Up / Down or k / j |
Move between sessions |
Enter |
Resume the highlighted session |
1 to 9 |
Resume the session at that position |
Space |
Preview the session |
Ctrl+R |
Rename the highlighted session |
/ or another printable key (not Space, j, k or a digit) |
Search; paste a pull request URL to find the session that created it |
Ctrl+A |
Show sessions from every project on this machine |
Ctrl+W |
Show sessions from all worktrees of this repository |
Ctrl+B |
Filter to the current git branch |
Esc |
Leave search or close the picker |
If you pick a session from an unrelated project, Claude Code copies a cd and resume command to your clipboard rather than switching folders for you.
How do you branch a Claude Code session?
Branching copies the conversation so far into a new session and switches you into it, leaving the original intact. Use it to try a different approach without losing the path you were on.
/branch try-streaming-approach
From the command line, add --fork-session to a resume:
claude --continue --fork-session
/branch prints two session IDs, the new branch and the original. The original stays in the picker, and you return to it with /resume. Because /branch runs in the same process, "Allow for this session" permission grants carry over. A --fork-session launch starts a new process, so you approve those again.
Do not resume the same session in two terminals without forking: the docs warn that messages from both interleave into one transcript. For parallel work on separate files, use git worktrees. For going back in time inside one session, use checkpoints and /rewind.
Where are Claude Code transcripts stored, and how do you export them?
By default transcripts live at ~/.claude/projects/<project>/<session-id>.jsonl. The <project> part is your working directory path with non-alphanumeric characters replaced by -. Each line is a JSON object, but the docs say the format "is internal to Claude Code and changes between versions," so scripts that parse it directly can break on any release.
For a readable copy, run /export, listed in the commands reference. It opens a menu to copy the conversation to the clipboard or save a plain-text file. Pass a filename, such as /export notes.txt, to write straight to a file.
For scripts, ask an existing session a question and parse the JSON:
claude -p --resume <session-id> --output-format json "summarize what we changed" | jq -r '.result'
Hooks and status line commands also receive a transcript_path field, so a SessionEnd hook can archive each transcript when a session ends.
Storage is configurable:
| To | Use |
|---|---|
Move storage off ~/.claude |
CLAUDE_CONFIG_DIR environment variable |
| Change the 30-day retention | cleanupPeriodDays in settings.json |
Skip transcript writes for one -p run |
--no-session-persistence |
| Skip transcript writes everywhere | CLAUDE_CODE_SKIP_PROMPT_HISTORY environment variable |
| Delete a project's transcripts now | claude purge |
How do sessions fit with /clear and /compact?
/clear starts a fresh conversation with empty context, but the old one is saved and you can get back to it with /resume. Pass a name, as in /clear release-prep, to label the session you are leaving. /compact keeps you in the same session and replaces history with a summary. /context shows what is using space. The context window guide covers when to pick each.
A simple habit that follows from the docs: name a session when you start real work, /clear between unrelated tasks, and come back with claude --resume <name> the next day. If you keep a standard opening prompt for picking work back up, such as "summarize where we left off and list open TODOs," Kipt can store it as Markdown in a private GitHub repo you own, with Cmd+K search to pull it up when you resume.