Resume Claude Code Sessions by Name and ID

1.Continue the latest session, or resume a specific one

Claude Code saves each conversation as a session, so an investigation doesn't have to end when you close the terminal. There are two ways back into one, and they differ in how you say which session you mean.

Continue needs no identifier. It finds the most recent session in the directory you are in. That is convenient when you only ever run one conversation at a time, and wrong the moment you have two: whichever you touched last wins.

Resume takes a specific session. You tell it which one, by ID or by name, and it reopens that conversation even when it isn't the most recent. The Agent SDK documentation puts the trade-off plainly: with resume, you track the ID. In return you can return to any past session, such as one per user in a multi-user app, or yesterday's investigation after you ran something else today.

Sources1

2.Naming an investigation so you can find it again

The answer to that prediction is the typo session, because continue only ever looks at the most recent one. Resume avoids the problem, but session IDs are opaque strings nobody remembers. Names fix that. You can give a session a name when you start it with claude -n auth-refactor, rename the current one with /rename auth-refactor, or highlight a session in the picker and press Ctrl+R. From then on, claude --resume auth-refactor goes straight back to it, which is what makes a named investigation something you can return to across several working days.

The CLI reference shows the short form, which also lets you hand the resumed session its next instruction in the same command:

claude -r "auth-refactor" "Finish this PR"

Two details decide whether a name resolves. First, the name has to match. On an exact match, claude --resume <name> resumes directly. If the name matches more than one session, it opens the session picker with the name pre-filled as a search term, whereas /resume <name> reports an error. Second, not every label you see is a name. Interactive sessions you never named get a default display name such as my-app-3f, built from the directory name and a two-character suffix. It appears in listings of running sessions, but it is not a resume handle, so passing it to --resume finds nothing. The title Claude Code generates from your first prompt is different: you can pass that title to claude --resume or /resume, and it resolves like a name you set yourself.

Sources23

3.What comes back when you resume

Resuming restores more than the chat text. The conversation comes back in full, tool calls and their results included. The session continues on the model it was using unless something overrides that, such as a --model flag or a retired model. A session started as a particular agent continues as that agent, with its tool restrictions. When you resume from a terminal, the permission mode is restored too, with some exceptions.

Some things do not come back. Scheduled tasks that haven't expired are restored, but background Bash and monitor tasks are not. A tool call that was still running when the previous process died, in a crash for example, isn't finished or re-run. Claude sees the call marked as cut off and is told to check whether it took effect before running it again.

The point to carry forward is what "full history, including tool results" means in practice. Every file Claude read, every grep it ran and every test output it saw is replayed exactly as it was recorded. Nothing is re-read. That is why resuming is cheap and fast, and it is also why the record can describe files that have since changed.

That reveal is the rule for resuming sessions after code modifications: the agent's picture of a file is the tool result it recorded, not the file on disk. If you edited or regenerated files after the session ended, the cheapest reliable fix is to say so in the first message of the resumed session, naming the specific files that changed. Informing the agent about changes to previously analyzed files turns the resume into a targeted re-analysis, where it re-reads only those paths, rather than a full re-exploration of the repository, and it removes the risk that it edits code based on a version that no longer exists.

That also gives you the decision between session resumption and starting fresh. Resume when the prior context is mostly valid: the analysis still describes the code, and only a handful of files need refreshing, which you can name. Start a new session with a structured summary injected into the first prompt when the prior tool results are stale, for example after a large refactor, a rebase or a generated-code rebuild. A fresh session carrying a short, accurate summary of what was learned is more reliable than a resumed one carrying pages of tool output that describe files as they used to be, because the stale results stay in the history and keep competing with whatever the agent reads next. Claude Code's own resume-from-summary option follows the same instinct: it runs /compact immediately and replaces the full history with a summary plus your most recent exchanges.

Sources21

4.Resuming from code with the Agent SDK

The Agent SDK exposes the same choice. Continue (continue: true in TypeScript, continue_conversation=True in Python) picks up the most recent session in the directory. To target a specific one, you capture the session_id from the result message of the first run and pass it back as the resume option on a later query().

The SDK documentation names three reasons to do this. One is following up on a completed task, so the agent acts on its earlier analysis without re-reading files. Another is recovering from a limit: if a run ended with error_max_turns or error_max_budget_usd, you resume it with a higher limit. The third is restoring a conversation after your process restarts, provided you saved the ID before shutdown.

// Earlier session analyzed the code; now build on that analysis
for await (const message of query({
  prompt: "Now implement the refactoring you suggested",
  options: {
    resume: sessionId,
    allowedTools: ["Read", "Edit", "Write", "Glob", "Grep"]
  }
})) {
  if (message.type === "result" && message.subtype === "success") {
    console.log(message.result);
  }
}

A session ID points to a file on disk, not to anything stored remotely. Claude Code searches beyond the current project directory for that ID, but only on the current machine, so the session file has to exist there. A resume that works on your laptop will find nothing on a fresh CI runner or a different container, because the transcript never left the machine that created it.

Resume appends to the original history, so a second resume of the same session sees everything the first one did. Sometimes that is not what you want. The SDK's session guide lists a fourth situation: you want to try an alternative approach without losing the original, and the answer there is to fork the session. A fork starts an independent branch that begins with the same recorded history but gets its own session, so work done on the branch never lands in the parent. From the CLI, that is claude --resume <session-id> --fork-session, or /branch from inside a session; the Agent SDK exposes the same switch as its fork option (fork_session), passed alongside resume.

The practical use is a shared analysis baseline. Run one session that explores the codebase thoroughly, capture its ID, then fork it twice: one branch is told to compare two testing strategies, or to try refactoring approach A, and the other is given approach B. Each branch starts from the same shared codebase analysis without repeating it, and because the branches are independent, the divergent approaches can be compared side by side and the losing one simply discarded. This is the parallel exploration pattern: fork_session for divergent approaches from a shared baseline, resume when you want a single conversation to keep going.

Sources14

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Any label shown for a session, including the default display name like my-app-3f, can be passed to claude --resume.Why is that wrong?

   The default display name only identifies running sessions in listings. Passing it to --resume finds nothing. Set a real name with claude -n or /rename, or use the generated title.

   Covered in Naming an investigation so you can find it again

2. 2.A session ID is a global handle, so any machine with the ID can resume the conversation.Why is that wrong?

   Resume reads the session file from local disk. The lookup searches beyond the project directory, but the file must exist on the machine doing the resuming.

   Covered in Resuming from code with the Agent SDK

3. 3.Resuming the same session twice with two different prompts gives you two independent branches to compare.Why is that wrong?

   Resume appends to one shared history, so the second run sees the first run's work. To try an alternative without touching the original, fork the session instead.

   Covered in Resuming from code with the Agent SDK

4. 4.Resuming after you edited files is safe because Claude re-reads them when the session comes back.Why is that wrong?

   Resume replays the recorded tool results; nothing is re-read. Tell the resumed session which files changed, or start fresh with a summary when most of the recorded results are stale.

   Covered in What comes back when you resume