Pick up where you left off in Claude Code

Server work rarely fits in one sitting. You start an upgrade, get interrupted, come back the next morning, and the conversation has grown so long that Claude Code has summarized half of it. This guide covers the four things that carry work forward: saved sessions, compaction, auto memory and the transcript file, plus what each one keeps and what it loses.

Every conversation is saved

Claude Code saves each conversation as you work, in a file per session: ~/.claude/projects/<project>/<session-id>.jsonl.

<project> is your working folder's path with every character other than letters and digits turned into -. The file holds the whole conversation, including every command Claude ran and what it returned. Claude Code deletes these files after 30 days by default. The cleanupPeriodDays setting changes that.

Resume a session

• claude --continue reopens the most recent conversation in this folder.
• claude --resume opens a list of past sessions to pick from.
• claude --resume <name> resumes the session with that name.
• claude --resume <session-id> resumes that session, from any folder.
• /resume switches to another conversation from inside a session.

--continue takes the most recent session, which isn't always the one you mean. In our test, we told Claude a fact in one session, opened a second, fresh session, and then ran claude -p --continue asking for the fact. It continued the second session, which had never heard it.

Names avoid that. Give a session a name when you start it, or rename it later with /rename:

$ claude -n nginx-upgrade

$ claude --resume nginx-upgrade

In our test, this worked for claude -p runs as well: a run started with -n nginx-upgrade came back by name after an unrelated run in between. Sessions from claude -p don't appear in the claude --resume list, but a name or a session ID still finds them.

What resuming brings back

A resumed session brings back the whole conversation, including the commands Claude ran and their output, and it continues on the same model. Some things don't come back on their own:

• Launch flags such as --add-dir, --mcp-config and --settings. Folders you added during the session with /add-dir aren't restored either. Settings files are read again at every start, so anything that lives in them carries over.
• Background commands. A command that was still running when the session ended doesn't come back. Claude sees a note that it didn't finish.
• The permission mode, partly. With claude --continue or claude --resume <name>, a session usually comes back in the mode it was in. Bypass and plan mode don't: the session starts in the mode a new one would. A session you pick from the list also starts in the mode a new one would.

When the conversation gets long

Every message you send carries the whole conversation with it. When it approaches the model's limit, Claude Code compacts it: it replaces the older part with a summary and carries on. You can also do it yourself at a natural break:

> /compact keep the upgrade plan and the list of changed config files

The text after /compact tells the summary what to keep. In our test, /compact shrank a conversation from 28,715 tokens to 2,522, and Claude still knew the fact we had told it earlier, the upgrade day.

What compaction keeps depends on where things came from. The documentation lists:

• Reloaded from disk: your project's root CLAUDE.md, auto memory, and the plan from plan mode.
• Re-read: up to five of the files Claude read or edited most recently.
• Summarized, so details can go: everything you only said in the conversation.

So if something must survive, put it in a file. Project rules go in CLAUDE.md. Facts go in auto memory, below.

/context shows what is taking up space right now. /clear starts an empty conversation for unrelated work. The old one is still saved and /resume brings it back.

Resuming after a break

On a Pro or Max plan, if you resume a session that has been idle for more than about an hour and holds more than 100,000 tokens, Claude Code asks how to continue:

• Resume from summary compacts it first. Later messages cost less, but anything the summary leaves out is gone from Claude's view.
• Resume full session as-is keeps every detail, at the cost of sending the whole history with each message.

For a long job where the details matter, such as a half-finished migration, resume in full. For a session you only want to finish off, the summary is enough.

Auto memory: facts that outlive the session

Resuming brings back one conversation. Auto memory carries facts into every new session in the project. Claude writes short notes for itself in ~/.claude/projects/<project>/memory/.

MEMORY.md there is an index, one line per note. The first 200 lines or 25 KB of it load at the start of every session, and Claude reads the notes themselves when it needs them.

To save something, just ask:

> Remember this for future sessions: in this project, the staging MariaDB listens on port 3307, not 3306.

In our test, Claude wrote a short note, staging-mariadb-port.md, and added one line to MEMORY.md pointing to it. It asked for no permission to do so, even in Manual mode. A brand-new session then answered "Port 3307", said it came from that note, and said it hadn't checked the live server. That last part matters: a memory records what someone said, not what the server is doing today.

When we asked it to remember something our CLAUDE.md already said, Claude declined and pointed to the line in CLAUDE.md. The documentation says auto memory skips anything your CLAUDE.md files already cover, and anything it can work out from the code.

A few points from the documentation:

• /memory lists the memory files and opens them in your editor. They are plain Markdown. Read them now and then, and delete what's wrong.
• Memory stays on the machine where it was written. Another server, or another user on the same server, doesn't see it.
• Unlike transcripts, memory files are not deleted after 30 days. They stay until you or Claude removes them.
• To turn it off, use the toggle in /memory, or set "autoMemoryEnabled": false in a project's settings.

Summaries can be wrong in the details

A compaction summary is written by the model. It gets the shape of the work right, but it can get a detail wrong, and nothing marks which details were lost.

We ran into this ourselves. A long session was compacted, and the summary described a mistake we had made. According to the summary, a backup copy had failed because of a shell alias, and a page had stayed live unreviewed for about a minute. When we wrote about it later, we checked the transcript first. The real cause was two files with the same name, and the page was live for about 26 seconds.

The transcript file is the record. The summary isn't. When a date, a count or the cause of an error matters, check it:

$ grep -o 'will not overwrite[^"]*' ~/.claude/projects/<project>/<session-id>.jsonl

The format of these files is internal and changes between versions, so use grep for a quick look and /export for a readable copy. Don't build a tool on the format.

A habit for long server jobs

Before you stop for the day, ask Claude to write the state of the job into a file in the project: what's done, what's half done, what's next, and how to undo each change. Next time, claude --resume brings back the conversation, and the file tells both of you where things stand, even if the conversation was compacted or you start a new one.

Sources

• Manage sessions, Claude Code documentation
• Explore the context window, Claude Code documentation, "What survives compaction"
• How Claude remembers your project, Claude Code documentation, "Auto memory"