Claude Code Side Chat for Client Work: Ask the Question Without Derailing the Build

What a Claude Code Side Chat Is

A side chat is a second, temporary conversation attached to the session you are already in. According to the desktop app documentation, it lets you ask Claude a question that uses your session's context but does not add anything back to the main conversation. You open it with Cmd+; on macOS or Ctrl+; on Windows, or by typing /btw in the prompt box. The side chat can read everything in the main thread up to that point. When you are done, you close it and continue the main session where you left off.

That is the whole feature, and it solves a problem every builder with a long client session has. You are forty minutes into a build, Claude is working through a plan, and you do not understand why it chose one approach in a file you did not write. If you ask in the main session, the question and the answer become part of the context Claude works from from then on. Sometimes that is fine. Often it nudges the session toward re-litigating a decision you had already settled. A side chat gives you the answer without the nudge.

This sits alongside the other session tools in the desktop app rather than replacing them. A new session (Cmd+N on macOS, Ctrl+N on Windows) is a separate piece of work with its own context. A side chat is a question about the work you are already doing. If you have not set up parallel sessions yet, [Claude Code git worktrees for client work](/blog/claude-code-git-worktrees-for-client-work) covers how to keep them from colliding.

Why Side Chats Matter on a Client Build

Client work punishes drift. You have a signed scope, a plan, and a session that is halfway through it. Everything you say in that session shapes what Claude does next, which is the entire point of [managing the context window on client work](/blog/claude-code-context-window-for-client-work). The cost of a careless question is not the tokens. It is that Claude now treats your curiosity as input.

Here is the pattern I see in builders who are new to this. They are mid-build, they wonder whether the client's export file might contain duplicates, and they type that into the main session. Claude, being helpful, starts handling duplicates. Now the build has a new requirement nobody agreed to, and it arrived by accident. That is scope creep with no client involved, and it is the kind of drift [a scope of work that prevents scope creep](/blog/scope-of-work-that-prevents-scope-creep) is meant to stop. The side chat is the guard on your own side of the table.

• Understanding code you did not write: ask what a function does or why a file is structured the way it is, without turning the question into a refactor request.
• Checking an assumption: ask whether something you believe about the client's system is plausible before you commit it to the plan.
• Drafting client communication: ask for a plain-English explanation of a technical decision for the weekly update, using what Claude already knows about the build, without cluttering the build history.
• Sanity-checking a decision: ask Claude to argue against the approach it just picked, and keep the argument out of the main thread unless it changes your mind.

The Parking-Lot Rule

The Parking-Lot Rule is one question I ask before I type anything mid-build: if the answer comes back as I fear, will it change the plan? If yes, it belongs in the main session, because the plan is exactly what the session needs to know about. If no, if the answer will only change what I understand or what I say to the client, it goes in a side chat. The idea is that the main session is the plan and the side chat is the parking lot where questions wait without blocking traffic.

The "side chat first" row is the one that earns its keep. When I doubt Claude's approach, the temptation is to challenge it in the main thread, which turns a hunch into a derailment. Asking the same question in a side chat costs nothing, and if my doubt turns out to be wrong, the main session never heard about it. If it turns out to be right, I go back and make a deliberate change to the plan, ideally using [plan mode](/blog/claude-code-plan-mode-for-client-work) so the change is reviewed before anything is edited.

What a Side Chat Does Not Do

The limits matter, because a feature that feels safe is easy to over-trust. A side chat reads the main thread up to the moment you open it. It does not see what happens in the main session afterward, so if Claude is still working while you ask, your answer is based on a snapshot. Ask the question, close the chat, and then check whether the main session moved in a way that makes the answer stale.

It also does not replace the people involved. A side chat can tell you what a piece of code probably does. It cannot tell you what the client's staff actually do with the output, or whether a record is meant to exist. Anything that depends on the client's real operation is a question for the client, not for a model, and the answer goes through the normal channel. If you inherited the project, [taking over a client's existing codebase](/blog/take-over-a-clients-existing-codebase) walks through which questions to ask the client instead of guessing.

Finally, it is not a safety boundary for the data. A side chat uses the same session context, which means anything sensitive in that context is in play. The rules in [is it safe to use Claude Code with client data](/blog/is-it-safe-to-use-claude-code-with-client-data) apply to a side chat the same as to the session it came from. If a file should not be in the session, it should not be in the conversation you are branching from either.

• It snapshots the main thread when you open it, so a long answer can go stale while the main session keeps working.
• It is not saved. Close the app and the side chat is gone.
• It cannot answer questions that depend on the client's real-world operation. Ask the client.
• It inherits the same data exposure as the session. Keep client data rules the same.

Using Side Chats With the Rest of Your Workflow

Side chats work best when the main session is disciplined: a written plan, a clear scope, and checkpoints you can return to if something goes wrong. With that in place, a side chat becomes a cheap second opinion during the build, not a way to rescue a messy one. If Claude has gone down the wrong path regardless, the answer is not a side chat; it is [stepping back when Claude writes the wrong code on a client build](/blog/claude-code-writes-wrong-code-on-a-client-build) and, if needed, rewinding with [checkpoints](/blog/claude-code-checkpoints-for-client-work).

One more use I like: the end-of-day check. Before I close a client session, I open a side chat and ask Claude to summarize what was done, what is unfinished, and what I told it that I should repeat to the client. The summary is for me, not for the build, so it does not belong in the main thread. I copy the useful part into the project notes, close the chat, and the next day's session starts clean.