Cursor extension: message-level fork controls disappeared (possible regression)
Resolved 💬 3 comments Opened Apr 6, 2026 by rebroad Closed Apr 6, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor)
responded on this thread — see the highlighted reply below.
What version of the IDE extension are you using?
openai.chatgpt 26.304.20706 (from ~/.cursor/extensions/openai.chatgpt-26.304.20706-linux-x64/package.json).
Which IDE are you using?
Cursor
What platform is your computer?
Linux
What issue are you seeing?
The “fork” icons/actions that previously appeared in conversation history (allowing fork from an earlier prompt/message) are no longer visible in Cursor.
I used to see explicit fork affordances at prior prompts; those controls have disappeared.
What steps can reproduce the bug?
- Open Codex in Cursor.
- Open an existing conversation with multiple prior prompts/messages.
- Hover or inspect message-level actions where fork controls were previously available.
- Observe that no fork action/icon is shown.
What is the expected behavior?
Message-level fork controls should be visible (or discoverable via an equivalent UI path) so a conversation can be forked from a prior message.
Additional information
- I verified that app-server still documents and exposes
thread/fork, so this appears to be extension/UI/integration behavior rather than backend API removal. - Version probing so far:
v0.116(exact alpha variant unknown): fork controls were not present.v0.117andv0.118: not yet tested.- If this behavior is intentional, please confirm whether message-level forking in Cursor was removed, gated, or relocated, and what the supported workflow is now.
- If unintentional, this may be a regression in extension UI behavior or capability gating.
3 Comments
We have never exposed fork controls on a per-message basis in the extension. You are correct that the underlying feature is available in the app server.
If you'd like to see this exposed in the client, please open a new feature request or upvote an existing feature request.
@etraut-openai Thanks for the response. Curious, I must have inadvertently exposed it in the client with the changes I made as it was working nicely within the Codex extension until I rebased to a newer upstream alpha. Thanks for the info to help me track down what happened (to make it both appear and disappear).
<img width="263" height="196" alt="Image" src="https://github.com/user-attachments/assets/f7e25888-2d49-4d78-bb6a-6fef5bb6646b" />
The icon previously appeared here, as a 3rd icon along with "copy", and "edit", there was a "fork" icon, which caused the conversation to be copied with the prompt ready-to-go (i.e. can either click send, or edit it first). So, I am baffled. I honestly thought the Codex extension had been improved with this feature, and it was a coincidence as I'd recently added an interactive forker to the TUI just because I needed this ability, which is why I'm wondering now (in hindsight) if I'd inadvertently enabled this feature within the extension somehow, as I'd like to get it back!
<img width="272" height="112" alt="Image" src="https://github.com/user-attachments/assets/93334b4f-4099-4384-a350-f86ed8a2c002" />
They are back! I really wish I knew why they keep re-appearing and going away! @etraut-openai are you 100% you've never exposed fork controls on a per-message basis in the extension, as this screenshot would appear to offer evidence to that contradicts that. Now that I've seen this surface again, I will try changing things in a more controlled/observable manner to see if I can make them disappear re-appear again, and report back if I can document something reproduce-able. I can confirm that it does not appear to be influenced by the codex binary itself (used by the extension).