Claude Code sessions: continue, clear, or start over

You close the terminal in the evening, and it feels like the whole conversation with the agent leaves with the window. An hour of discussion, the bugs you tracked down, the context you explained - all of it seems to be gone.

It isn't. The conversation writes itself to disk while you work, and a single command opens it again.

The easiest way to picture sessions is a hotel. The project folder is the building, each conversation is a room, and the keys to every room hang on a board behind the front desk. You leave in the evening, but you don't check out of the room: the key goes back on the board, your things stay inside. In the morning you just tell the clerk which room you need.

The analogy has a limit, and it's worth drawing right away: the rooms hold conversations, not code. The code is the building itself, shared by every guest.

Below: what a session is, three ways back into one, why a conversation needs a name, and why a new task belongs in a new conversation instead of being tacked onto an old one.

What a session is

A session is a saved conversation with the agent, tied to the project folder. It's written to disk continuously as you work: there's nothing to save by hand the way you would in a text editor.

A session holds more than the lines of dialogue. Along with your messages and the agent's answers it keeps the tool calls and their results: which files it opened, what came back from the commands it ran, which edits it applied. That's why coming back to an old conversation gives you the whole picture rather than a summary of it.

Two clarifications, and they clear up half the confusion.

What's in one conversation doesn't carry over into another. If you discussed something a month ago in a different session, none of it is here, even for the very same project. Each session knows its own history and nothing beyond it.

A session isn't a second place where the code lives. Project files sit on disk on their own. One project gets along fine with a dozen sessions, and they all share the same code - whatever is in the folder right now.

The diagram shows both ideas at once: one folder, several sessions inside it, each with its own history, and shared files at the bottom. Opening a second session on the same project doesn't copy the code; it just adds one more conversation about it.

Getting back to work

There are three ways in, and the choice depends on whether you remember which conversation you need.

One thing in the table is easy to miss: the top two rows start with claude, the bottom one with a slash. That's not cosmetic. The top two are typed in the terminal, before the agent is running, and the flag there is part of the launch command itself. So one action both starts the agent and tells it which conversation to open:

claude              # launch with a clean slate
claude --continue   # launch straight into yesterday's conversation
claude --resume     # launch and pick a conversation from the list

/resume works the other way around, from the inside: the agent is already open, you type into its input line and switch to another conversation without going back to the terminal.

In practice the difference is simple. claude --continue says "I was working here yesterday, let me carry on": the agent quietly opens the last conversation in the current folder. claude --resume says "there are several, let me choose".

The list gives one row per conversation: the name if you set one, otherwise an automatic title, how long since the last activity, the branch, and the size. When there are many rows you can search them just by typing, or widen the list beyond the current folder - Ctrl+A shows conversations from every project on this machine.

Everything that was in the conversation comes back with it: the full history, tool calls and their results included. The same model is usually kept too, as long as it's still available and your settings haven't changed. You continue from exactly where you stopped.

Why a session needs a name

With one conversation you don't need a name. As soon as there are three, the list turns into a puzzle: two of them start the same way, and the third is anyone's guess.

There are two ways to set one:

claude -n feedback-form   # at launch
/rename feedback-form     # inside an open session

If you don't set a name, Claude Code makes up a short title from your first message. That works as a label too: the session shows up in the list and opens fine. Your own name is simply more precise - an automatic title describes your opening sentence, not the task as a whole.

Honestly, people rarely name a conversation at the start: you don't know yet what it will grow into. Half of all sessions begin as "let me just look at one line", and some of them unexpectedly turn into half a day of work.

So the easier approach is this. Leave a short visit alone; the automatic title is enough. Realized you're in for the long haul? /rename as you go. Finished? /clear with a name: the task is behind you, and what to call it is no longer a question.

New task, new conversation

There's only one question to keep asking as you work: is this still the same task? While it is, you carry on. When it changes, you start with a clean slate. It sounds like a formality, and yet this is where conversations most often turn into a mess.

The temptation makes sense: the agent already knows the project, so why start over. But a conversation with three tasks dumped into it goes wrong in predictable ways:

• it drags decisions from the old task into the new one. An hour ago you agreed on one approach; now you're doing something else, and it remembers the first agreement and keeps steering back to it;
• ideas you already rejected float back up. You rejected them in a different task, but to the agent it's all one stream;
• while it's at it, it edits things that belonged to the earlier task. You asked about the form and got changes in the payment code as a bonus;
• the changes get mixed together. One conversation, edits on two topics, and later it's hard to tell which belonged to what;
• you can't find the conversation in the list. It's about everything at once, which means about nothing.

Hence a simple rule: a conversation lives exactly as long as it helps one task. The task ends and so does the conversation. A session here is a consumable, not something you look after.

There are two ways to get a clean slate, and the difference between them is smaller than it looks.

Now about /clear, because this is where people get nervous most often. The command looks like a delete and behaves like a switch: it doesn't erase the conversation; it sets it aside and opens an empty one. The one you set aside stays in the list and opens through /resume exactly as you left it.

It takes an optional argument, a name. /clear feedback-form labels the departing conversation in the list so you can recognize it later. A second of work, and much less hunting afterward.

There's a flip side. If the conversation already has a name - from -n at launch or /rename along the way - a bare /clear hands that name to the new conversation, and your next task ends up labeled with the previous one's name. With the argument, the name stays with the old conversation and the new one starts unnamed.

Look at the top row. In this launch there's one active conversation before the command and one after. /clear doesn't open a second session next to the first: it swaps the active conversation for an empty one and moves the old one down into the list. Landing back in it takes a deliberate step, through /resume.

A new session differs from /clear in that it usually means different work as well: another project, another folder, another day. /clear doesn't take you out of the current directory or the current launch - it opens a clean slate right where you're standing.

There is also /compact. That one isn't about switching tasks but about the length of the conversation: it folds what's already been said into a summary and leaves you in the same session. It's easier to cover alongside how the context window works and what happens when it runs out, which is a topic of its own.

Where all this lives and how long it is kept

The conversations sit on your own disk, in Claude Code's data folder:

~/.claude-codegym/projects/

The ~ sign means the user's home folder. On Windows that's %USERPROFILE%, so the training path starts with %USERPROFILE%\.claude-codegym\projects\.

.claude-codegym is the training profile. If Claude Code runs without it, the standard path is ~/.claude/projects/. Inside there's a subfolder per project, and inside that one main file per conversation.

Conversations aren't kept forever: after roughly a month the old ones are cleared out automatically, together with the checkpoints that belong to them, and the period is configurable. So a session is a good place to work on a task and a poor place for the long-term history of a project. What people use for that is a big topic of its own.

What this changes in your work

A few conclusions you can use tomorrow:

• a session is a container for one task, not a lifetime of correspondence with the agent. The closer you keep it to that, the less often the agent gets confused;
• the conversation saves itself; there's nothing to save by hand. Closing the terminal in the evening costs you nothing;
• sessions are organized by folder. Start the agent from the project folder and its conversations are at hand; if the list is empty, check the folder: Ctrl+A shows conversations from every project and tells you where to go;
• coming back to an old conversation brings back all of its context, dead ends and discarded ideas included. Sometimes starting over is faster than reviving a three-hour discussion;
• one folder with a dozen sessions in it is a perfectly normal setup, not a sign of disorder.

Where session files are stored, what the list shows, and how long things are kept depend on your Claude Code version and settings, so yours may differ from what is described here.