Cursor Side Chats: Branch a Question Without Derailing

Cursor's help page defines it exactly: "A side chat is a full agent conversation that runs next to your main chat. The parent's conversation history is copied in as reference context for the model." It is a durable child conversation with its own transcript, attached to the parent agent and to the workspace. The case it covers is a tangent that arrives mid-task, when you don't want to crowd the main thread or stall the agent working in it.

The line on that help page that changes how you work is the one about defaults. Side chats focus on reading, searching and answering, which is what keeps the parent out of trouble. Two agents writing into the same working tree is a merge problem you have to plan for. A side chat pointed at a question stays on the reading side of that, so the cost of branching one is mostly the attention you spend reading the answer. Parallel edits are a different job, and worktrees are still the tool there.

The last row of that table carries a cost it doesn't mention. Parent history reaches the model as context you can't see, so when a side chat answers strangely there is no transcript to inspect for the reason. The likely culprit is something you settled early in the parent thread and have since forgotten. Write the assumption into the side-chat prompt anyway, even when the parent already carries it.

Which route you use decides what the side chat starts out knowing. /side opens an empty one and you type the question, or you append it to the command and send both at once. Selecting text or a diff in the chat, then choosing Ask in Side Chat, pins that selection as the subject. For a question about a specific diff, that is the route to take, because describing the diff in prose is work you don't need to do.

1. 1Type /side in the chat input, optionally with the question appended, e.g. /side why does this migration lock the table?
2. 2Select text or a diff in the chat, then choose Ask in Side Chat from the selection menu. The selection becomes the side chat's subject.
3. 3Press ⇧+⌘+S (Mac) or ⇧+Ctrl+S (Windows/Linux) to populate a side chat with the current transcript selection.

Closing archives rather than deletes. The X button archives the side-chat agent and the conversation itself stays. Same if you navigate away. A side chat is scoped to its parent agent and workspace, so it stays attached to that parent even once you have started a new conversation elsewhere, and it persists until you archive it by closing it. To bring a conclusion back, @-mention the side chat from the main thread.

Those three entry points are the ones the help page documents. The 3.11 release notes name two more: /btw, and the plus button at the top of the chat panel.

No. Forking makes a full copy of the parent conversation, every message and subagent included, and hands you a second thread to take down a different path. A side chat copies nothing into its own transcript: the parent history is seeded to the model as hidden context and never rendered.

Fork when you intend to rerun the work differently. A side chat is for asking about it while it keeps going, a much smaller commitment that suits a question you might abandon two replies in.

Most of the advice on this site pulls the other way, toward one task per chat and a fresh thread so stale context doesn't drag the model off course. For a while I would have called side chats a straight exception to that. They aren't, quite. The rule holds, because a question about the task in front of you isn't a second task, and the test that actually helps is not "new chat or side chat" but whether answering the question needs to know what the agent is doing right now. When it doesn't, open a new chat, since parent history is dead weight there.

Every use that sticks has the same shape. The question needs to know what you are in the middle of, and the answer isn't worth stopping the agent for.

• Review-time questions. The agent produced a diff; ask "is this pattern safe with our auth middleware?" in a side chat instead of derailing the implementing conversation.
• Competing approaches. Explore "what would this look like with a queue instead?" while the main agent finishes the current approach.
• Rabbit holes with a return ticket. Debugging tangents get their own transcript, and the answer comes back via @-mention rather than scrolling.

The expensive failure is the side chat that quietly becomes the real conversation. You open one to sanity-check an approach, the answer is good, you follow up a few times, and the decision that now governs the work lives in a thread the parent knows nothing about. Nothing merges by itself. Come back a week later and the main transcript reads as though that decision was never taken, which is also the version your teammate gets when they pick the ticket up. The fix is cheap and easy to forget. @-mention the side chat back into the main thread while the conclusion is still fresh, or paste the two-line summary in yourself.

On a team of three this barely registers, since whoever opened the side chat is the person doing the work.

It starts to matter at the size where somebody else picks up the ticket, and especially where review is a separate person's job rather than a step you do to yourself. The rule that seems to hold there is to @-mention any side chat that changed the plan back into the parent before the work goes for review.

Side chats shipped in Cursor 3An older release label for Cursor's multi-agent interface; current product guidance calls the active surface the Agents Window. Press Enter for the full definition..11 alongside its retrieval half: conversation search. From the Agents WindowCursor's surface listing your agent runs; open a run to read its diff and search transcripts from the command palette. Press Enter for the full definition., ⌘/Ctrl+K searches across past agent transcripts (Cursor builds a local index that scales to thousands of conversations), and ⌘/Ctrl+F searches within an open conversation with a match counter. Between the two, an archived side chat is findable by what was said in it. That is the handle you will actually have, because a week later you remember the question and not which parent thread it hung off.

If a search comes up empty, the explanation is usually scope rather than the index. Side chats stay attached to a parent agent and a workspace, so check you are in the workspace the parent lived in, then check whether you closed it, since closing archives. Neither of those loses the thread.

What you cannot do yet is reach one from a Cloud Agent. Side chats are local-only for now, with cloud support listed as coming soon, so a remote-supervision habit built on them will break.