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

[ariane-emory]

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.

[github-actions[bot]]

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.

[ariane-emory]

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]

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.

[KiKaraage]

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

[ariane-emory]

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.

[rekram1-node]

Hm idk this seems more complicated and kinda unintuitive

[ariane-emory]

@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.

[rekram1-node]

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

[ariane-emory]

@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.

[rekram1-node]

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

[ariane-emory]

@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.

[rekram1-node]

Yep that sounds good