After I get a full answer to question A in the parent chat, I Fork the conversation and ask a new question B only in the forked chat.
The agent’s reply in the fork re-answers A (often a shorter regenerated version), then answers B.
The fork should already include context up to the fork point (including the assistant’s answer to A). Instead, the model behaves as if A was never answered.
This makes Fork Chat unreliable for branching into a side question without redoing the previous turn.
Steps to Reproduce
Open Agent chat (local).
Ask question A, e.g. “Give me a detailed comparison of Option 1 vs Option 2 for this project.”
Wait for a complete assistant reply to A.
Fork the chat.
In the forked chat only, ask question B — a different topic, e.g. “What do you think of this email? Should I reply?” and paste unrelated content.
Observe: the forked reply re-summarizes or re-answers A before answering B.
Expected Behavior
The fork keeps context up to the fork point (per Cursor docs: “all context up to the selected point”).
If I fork after the assistant has answered A, the first reply in the fork to question B should address B only (or briefly say “covered above”), not regenerate the full answer to A.
Hey, thanks for the detailed report and steps. This is a bug on our side, and your expectation is correct. A fork should keep all context up to the fork point, including the assistant’s last reply.
It only reproduces when you fork from the last turn using the button on that message. In that case, the previous reply gets dropped, and the model answers as if A never got a response.
Workaround for now: don’t fork via the action on the specific message. Use the /fork slash command in the input box, or use Fork Chat from the ⋯ menu in the chat list. Both options clone the full checkpoint and keep the last reply, so your new request B will be answered as just B.
We’ve logged the bug, but I don’t have an exact ETA for the fix yet. I’ll post an update in the thread as soon as I have one.
Your workaround (/fork / chat-list Fork) clones the current end of the chat. That doesn’t help when I want to branch from a specific earlier reply after the parent chat has moved on.
Is that use case possible right now, or not until the bug is fixed?
Good question, and the honest answer is that you can’t reliably do this right now.
Branching from a specific earlier reply is done via the fork button on that message. That’s exactly what’s currently bugged and loses context. The reliable workarounds (/fork and Fork Chat from the ⋯ menu) only clone the current end of the chat, so they don’t cover your case. You want to branch from an earlier point after the parent chat has already moved on.
So proper branching from any earlier point will work once the bug is fixed. I can’t share an ETA yet, but I’ll post an update in the thread as soon as I have one.
As a temporary workaround, if you specifically need to go back to an earlier point, roll back to the right checkpoint in the original chat and run /fork from there. The fork will copy the state from that point. It’s not as convenient as forking from the message, but it should keep context correctly.
The fix for the fork that was replying to the previous request is included in Cursor 3.14. Once you update to that version, please try again. Forking from a specific earlier reply should also correctly keep context after this update.
Until 3.14 is out, the previous workarounds still apply: use /fork or Fork Chat from the ⋯ menu to fork from the current end of the chat. For an earlier point, roll back to the right checkpoint in the original chat, then run /fork from there.
If, after updating, any scenario still doesn’t behave as expected, post here and I’ll take a look.