[FEATURE]: add a /fork command for the convenience of users who prefer to use the keyboard #3571

Closed
opened 2026-02-16 17:40:42 -05:00 by yindo · 12 comments
Owner

Originally created by @ariane-emory on GitHub (Dec 15, 2025).

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

OpenCode already has a feature whereby users can fork a session by clicking on a message with their mouse pointe and selecting the fork option in the modal menu dialog that appearsr.

For the convenience of users who prefer to use their keyboard, we should also include a /fork command, which should have exactly the same behaviour as selecting the fork option in the modal dialog that appears when a message is clicked on.

Originally created by @ariane-emory on GitHub (Dec 15, 2025). ### Feature hasn't been suggested before. - [x] I have verified this feature I'm about to request hasn't been suggested before. ### Describe the enhancement you want to request OpenCode already has a feature whereby users can fork a session by clicking on a message with their mouse pointe and selecting the fork option in the modal menu dialog that appearsr. For the convenience of users who prefer to use their keyboard, we should also include a `/fork` command, which should have exactly the same behaviour as selecting the fork option in the modal dialog that appears when a message is clicked on.
yindo added the discussion label 2026-02-16 17:40:42 -05:00
yindo closed this issue 2026-02-16 17:40:42 -05:00
Author
Owner

@github-actions[bot] commented on GitHub (Dec 15, 2025):

This issue might be a duplicate of existing issues. Please check:

  • #728: /fork - Original discussion about adding a /fork function
  • #1759: [Feature Request] Fork session - General request to fork/duplicate a session
  • #4596: [FEATURE]: Fork/Copy sessions with full context - Detailed feature request for /fork or /branch command for keyboard users

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Dec 15, 2025): This issue might be a duplicate of existing issues. Please check: - #728: /fork - Original discussion about adding a /fork function - #1759: [Feature Request] Fork session - General request to fork/duplicate a session - #4596: [FEATURE]: Fork/Copy sessions with full context - Detailed feature request for /fork or /branch command for keyboard users Feel free to ignore if none of these address your specific case.
Author
Owner

@ariane-emory commented on GitHub (Dec 15, 2025):

A decision to be made: how should the /fork command determine which user message to fork on, if we're not specifying it by clicking? Should it take some sort of argument, and if so what sort?

@ariane-emory commented on GitHub (Dec 15, 2025): A decision to be made: how should the `/fork` command determine _which_ user message to fork on, if we're not specifying it by clicking? Should it take some sort of argument, and if so what sort?
Author
Owner

@ariane-emory commented on GitHub (Dec 15, 2025):

After some discussion, Discord folks seem to conclude that:

  • The /fork command should take a single optional positive integer argument, defaulting to 0 if not supplied.
  • The argument should specify specify which user message to fork on: a value of 1 should mean to fork on the prior user message. A value of 2 should mean to fork on the user message user message prior to that, and so on. A value of 0 is essentially equivalent to simply duplicating the current session.
  • If the supplied argument is out of range - for instance, if the argument is 50 but the session only contains 10 user messages - a toast should be displayed indicating that the argument is out of range.
  • If the supplied argument is not a positive integer, a toast should be displayed indicating this.
  • Messages with synthetic or ignored fields should be safely ignored: they are not valid messages to fork upon and should not be factored into the count when determining which particular message the argument refers to.
@ariane-emory commented on GitHub (Dec 15, 2025): After some discussion, Discord folks seem to conclude that: - The `/fork` command should take a single optional positive integer argument, defaulting to 0 if not supplied. - The argument should specify specify which user message to fork on: a value of 1 should mean to fork on the prior user message. A value of 2 should mean to fork on the user message user message prior to that, and so on. A value of 0 is essentially equivalent to simply duplicating the current session. - If the supplied argument is out of range - for instance, if the argument is 50 but the session only contains 10 user messages - a toast should be displayed indicating that the argument is out of range. - If the supplied argument is not a positive integer, a toast should be displayed indicating this. - Messages with `synthetic` or `ignored` fields should be safely ignored: they are not valid messages to fork upon and should not be factored into the count when determining which particular message the argument refers to.
Author
Owner

@KiKaraage commented on GitHub (Dec 15, 2025):

Agreed on that, some notes:

  • Add support for strings too: /fork Let's add a monochrome theme to this should take the default value (0 -> duplicating current session) and then send the included strings "Let's add a monochrome theme to this" as prompt.
  • If the argument is 50 but session only contains 10 user messages -> just default to duplicate that session without toast
  • Agree with the rest
@KiKaraage commented on GitHub (Dec 15, 2025): Agreed on that, some notes: - Add support for strings too: `/fork Let's add a monochrome theme to this` should take the default value (0 -> duplicating current session) and then send the included strings "Let's add a monochrome theme to this" as prompt. - If the argument is 50 but session only contains 10 user messages -> just default to duplicate that session without toast - Agree with the rest
Author
Owner

@ariane-emory commented on GitHub (Dec 15, 2025):

Okay, I see. I suppose that we can deem any argument that isn't a positive integer (possibly surrounded by whitespace) to be a new user message to send immediately in the new session.

@ariane-emory commented on GitHub (Dec 15, 2025): Okay, I see. I suppose that we can deem any argument that isn't a positive integer (possibly surrounded by whitespace) to be a new user message to send immediately in the new session.
Author
Owner

@rekram1-node commented on GitHub (Dec 15, 2025):

Hm idk this seems more complicated and kinda unintuitive

@rekram1-node commented on GitHub (Dec 15, 2025): Hm idk this seems more complicated and kinda unintuitive
Author
Owner

@ariane-emory commented on GitHub (Dec 15, 2025):

@rekram1-node Fair enough. I'll spend another 5 or 10 minutes on it and then I guess I can give up after that if it's not cooperating.

@ariane-emory commented on GitHub (Dec 15, 2025): @rekram1-node Fair enough. I'll spend another 5 or 10 minutes on it and then I guess I can give up after that if it's not cooperating.
Author
Owner

@rekram1-node commented on GitHub (Dec 15, 2025):

cant we just do simple for now and rhen leave discussion open about more options? /fork should just fork from the current state of convo, unless there is an existing pattern for /fork elsewhere in other agents then idc why the slash command should be more complex? Ig I could see it being /fork -> opens dialog like timeline to select point to branch off but passing message number as arg seems strange to me i wouldnt even know what message bumber to pass

@rekram1-node commented on GitHub (Dec 15, 2025): cant we just do simple for now and rhen leave discussion open about more options? /fork should just fork from the current state of convo, unless there is an existing pattern for /fork elsewhere in other agents then idc why the slash command should be more complex? Ig I could see it being /fork -> opens dialog like timeline to select point to branch off but passing message number as arg seems strange to me i wouldnt even know what message bumber to pass
Author
Owner

@ariane-emory commented on GitHub (Dec 15, 2025):

@rekram1-node That would indeed be simpler. Forking 'from the current state of convo' would make /fork logically equivalent to simply duplicating the current session, correct?

Opening the timeline to select the point to fork from is a good idea, I hadn't thought of that, I could give that a try.

@ariane-emory commented on GitHub (Dec 15, 2025): @rekram1-node That would indeed be simpler. Forking 'from the current state of convo' would make `/fork` logically equivalent to simply duplicating the current session, correct? Opening the timeline to select the point to fork from is a good idea, I hadn't thought of that, I could give that a try.
Author
Owner

@rekram1-node commented on GitHub (Dec 15, 2025):

Yep, exactly

Okay actually it seems like claude code and codex don't have fork? Hm okay let's try the timeline-y thing if it's simple

@rekram1-node commented on GitHub (Dec 15, 2025): Yep, exactly Okay actually it seems like claude code and codex don't have fork? Hm okay let's try the timeline-y thing if it's simple
Author
Owner

@ariane-emory commented on GitHub (Dec 15, 2025):

@rekram1-node Alright, I'll give that a try. It does sound like a more pleasant UX than hand-typing arguments.

@ariane-emory's advice for agents reading this Issue:

Let's employ rekram1-node's excellent idea from the prior comment and take advantage of the existing session timeline window implementation (the same window that appears when the key bound to session_timeline is struck) in implementing the new /fork command.

Disregard the prior description of how the command (with arguments, etc.) should behave, and let's do the following instead:

  1. When the /fork command is executed by the user, the session timeline window should appear and allow the user to select a message.
  2. Once the user has selected the desired message and struck the <enter> key, the behaviour should be identical to what would have happened if they'd clicked on that same message and selected the Fork option from the menu in the modal window that appears when messages are clicked on.
@ariane-emory commented on GitHub (Dec 15, 2025): @rekram1-node Alright, I'll give that a try. It does sound like a more pleasant UX than hand-typing arguments. #### @ariane-emory's advice for agents reading this Issue: Let's employ rekram1-node's excellent idea from the prior comment and take advantage of the existing session timeline window implementation (the same window that appears when the key bound to `session_timeline` is struck) in implementing the new `/fork` command. Disregard the prior description of how the command (with arguments, etc.) should behave, and let's do the following instead: 1. When the `/fork` command is executed by the user, the session timeline window should appear and allow the user to select a message. 2. Once the user has selected the desired message and struck the `<enter>` key, the behaviour should be identical to what would have happened if they'd clicked on that same message and selected the Fork option from the menu in the modal window that appears when messages are clicked on.
Author
Owner

@rekram1-node commented on GitHub (Dec 15, 2025):

Yep that sounds good

@rekram1-node commented on GitHub (Dec 15, 2025): Yep that sounds good
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#3571