Claude Code Sessions for Client Work: Name, Sort, and Close Out Every Client Conversation

What a Claude Code Session Is

A session is a saved conversation tied to a project directory. In the desktop app's Code tab, each session has its own chat history and project folder, independent of any other session, and the sidebar lists them all. You start one with + New session in the sidebar, or Cmd+N on macOS and Ctrl+N on Windows, and cycle through them with Ctrl+Tab and Ctrl+Shift+Tab. To see two at once, hold Cmd (or Ctrl) and click a second session to open it in a split pane.

That sounds like housekeeping, and it is. But on client work, housekeeping is margin. A builder with three active clients and a maintenance retainer will open dozens of sessions a month. If they are all called something like the first line you typed, finding last Tuesday's database fix for one client means opening sessions one by one. The cost is not the minutes. It is the risk of continuing the wrong conversation on the wrong client's code.

The One-Client-One-Folder Rule

The rule is three habits. First, every client gets its own project folder, and every session for that client starts in it. Second, every session gets a name that starts with the client and says what the piece of work is. Third, a session ends when its piece of work ends, and gets archived instead of reused for the next task. The point is that your sidebar should read like your client list, not like a history of things you typed.

The desktop app gives you what you need for all three. Use the controls at the top of the sidebar to group sessions by project, and each client's folder becomes its own group. Filter by status when you want only what is still running. Rename a session by clicking its title in the toolbar at the top of the active session. If you accept a plan in [plan mode](/blog/claude-code-plan-mode-for-client-work), Claude Code gives an unnamed session a title based on the plan, which is a decent fallback, but I would still put the client's name in front of it.

The third habit is the one builders skip. Reusing yesterday's session for today's task feels efficient, because Claude already knows the project. But the project knowledge belongs in the client's instruction file, not in an old conversation. Put it in [a CLAUDE.md file for the client project](/blog/claude-md-file-for-client-projects) and every new session starts with it. Then a fresh session per task costs you nothing, and [managing the context window](/blog/claude-code-context-window-for-client-work) gets much easier.

Parallel Sessions on One Client

When one client has two pieces of work going at once, say a bug fix and a new report, run them as two sessions. For Git repositories, select the worktree option next to the branch name when you start the session, and it gets its own isolated copy of the project, so changes in one session do not affect the other until you commit them. [Claude Code git worktrees for client work](/blog/claude-code-git-worktrees-for-client-work) covers the setup, including how to bring gitignored files like .env into a new worktree.

Two settings make this tidy. In Settings, under Claude Code, you can set a branch prefix that gets prepended to every worktree branch name, and putting the client's name there keeps Claude-created branches easy to read in the client's repository. You can also turn on Auto-archive after PR merge or close, so a session archives itself once its pull request is done. Auto-archive only applies to local sessions that have finished running.

When a session is going well but you want to try a different approach, do not fork the client's work by hand. In the terminal, /branch copies the conversation so far into a new session and leaves the original intact, so you can test an idea and go back if it fails. For rewinding within a single session, [checkpoints](/blog/claude-code-checkpoints-for-client-work) are the better tool.

Cross-Session Awareness: Useful, and a Reason to Be Deliberate

This is the part every multi-client builder should read twice. According to the desktop documentation, Claude can list your other Code tab sessions, read what each has been doing, and send messages between them. You can ask in plain language: which session touched the report, what did the API session conclude, tell the payments session the schema changed. You can also ask Claude to rename or archive a session, and it asks for your approval before archiving, in every permission mode.

Inside one client's work, that is a genuine time saver. The bug-fix session can tell the reporting session that a column was renamed, and you do not have to relay it. Across clients, it is a reason to be deliberate. The desktop app sees the sessions it runs itself, local, SSH, and WSL, and by default Claude sees the 20 most recently active ones, skipping archived sessions unless you ask. So if two clients' sessions are open side by side, a careless question like 'what did the other session decide?' can pull one client's work into another client's conversation.

• Name sessions by client, so any cross-session question you ask is explicit about which client it means.
• Ask cross-session questions only within one client's group. Never ask a session to summarize 'everything I am working on'.
• Archive finished client sessions. Claude cannot deliver messages to an archived session and skips archived sessions by default.
• If a client's data is sensitive, follow the same rules you use everywhere in [is it safe to use Claude Code with client data](/blog/is-it-safe-to-use-claude-code-with-client-data), and consider not running that client's sessions alongside anyone else's.

Closing Out a Client Session

A session is not a record. The desktop app keeps its own session list, the CLI stores transcripts locally, and neither is where your client should have to look for what happened. Before you archive a session, move anything that matters into the places that last: the decision into the project's instruction file or the plan, the change into a commit with a clear message, and the summary into your [weekly client update](/blog/weekly-client-update-prevents-fires). If you work in the terminal, /export saves the conversation as a plain-text file, which is handy for your own notes on a tricky fix.

My end-of-task routine is short. Ask Claude to summarize what changed and what is left, copy the useful part into the client notes, confirm the work is committed, then archive. If the work will continue tomorrow, I leave the session open with a name that says so. Everything else goes. The sidebar stays a list of live client work, which is exactly what you want to see when you open the app in the morning and decide where the day goes.

Running several clients at once is its own skill, and sessions are only one layer of it. [Running multiple Claude Code client projects at once](/blog/run-multiple-claude-code-client-projects-at-once) covers the scheduling and communication side. Sessions are the layer that keeps the code side from blurring together.