Docs contradict each other on what Fork Chat copies (3.17.19)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

This is a documentation defect. The docs give two incompatible descriptions of what Fork Chat copies, and they imply opposite outcomes for the same click.

The contradiction

The 0.50 changelog introduced the feature as Duplicate Chats:

Exploring different paths from a conversation while preserving the existing. Go to a message and start a new chat from a message in the three dots menu.

“Start a new chat from a message” reads as: the fork begins at that message.

But Side chats says:

Forking creates a full copy of the parent conversation, including all messages and subagents.

“All messages” reads as: the fork contains the whole conversation and the fork point does not matter.

The 2.5 changelog (cursor.com/changelog/2-5) renamed Duplicate Chat to Fork Chat without clarifying which is right.

Steps to Reproduce

  1. Read the Fork Chat description in the 0.50 changelog linked above.
  2. Read the forking description on the Side chats help page linked above.
  3. Note that the two descriptions are incompatible.
  4. In Cursor 3.17.19, open a conversation with several messages, open the three-dot menu on a message partway through, and choose Fork Chat.
  5. Compare the resulting chat’s contents against both documented descriptions.

Expected Behavior

The documentation should state plainly which messages end up in the fork.

Why this matters

The two readings lead to opposite decisions:

  • If you believe “full copy”, you would never reach for Fork to trim a conversation — which is currently the only way to do it at all.
  • If you believe “starts from that message”, you might fork expecting the later messages to survive somewhere, and be surprised when they do not.

One of those loses work. Please state plainly which messages end up in the fork.

Operating System

Windows 10/11

Version Information

3.17.19 (Windows 11, build 26200)

Additional Information

Actual behavior

Tested in 3.17.19 on Windows. Forking from a message produces a new chat containing the conversation from the beginning through the message you forked on. Everything after that point is not carried over.

So the changelog wording is effectively correct and the side-chats page is misleading.

Also unspecified

The side-chats page says subagents are included. If subagents are attached to messages after the fork point, what happens to them — dropped, or re-parented? This is not cosmetic: subagent parent/child linkage determines whether a conversation appears in the top-level chat list at all.

One more docs request

Restore Checkpoint is easy to misread as history rollback. Agent overview (cursor.com/docs/agent/overview) and Agent help (cursor.com/help/ai-features/agent) describe it as rolling back files, but it sits in the chat timeline next to your messages and reads like it reverts the conversation. An explicit “this does not remove messages from the conversation” line would save people a lot of confusion.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey @Steve_Carlisle, thanks for the report!

Your testing matches how it works:

  • Forking from a message copies the conversation from the beginning through that message. Anything after it isn’t carried over.
  • Forking the whole chat (from the tab or sidebar menu) copies the full conversation.
  • Subagents from the copied portion come along and are attached to the new chat; subagents after the fork point aren’t included.
  • Restore Checkpoint only reverts file changes, it never removes messages from the conversation.

We’ll get the docs updated to state this plainly.