anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 10:15:31 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[FEATURE]: Add cli flag to fork session #7945

New Issue
Closed
opened 2026-02-16 18:08:44 -05:00 by yindo · 6 comments
yindo commented 2026-02-16 18:08:44 -05:00
Owner
Copy Link
Copy Source

Originally created by @moonray on GitHub (Jan 29, 2026).

Originally assigned to: @thdxr on GitHub.

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

I know there is a fork ability in ui, but it would be great if we could fork using a cli flag for better automation and tooling.

Claude uses the following:

  --fork-session                                    When resuming, create a new session ID instead of reusing the original (use with --resume or --continue)

e.g.

opencode --continue --fork-session

or

opencode --session [session_id] --fork-session
Originally created by @moonray on GitHub (Jan 29, 2026). Originally assigned to: @thdxr on GitHub. ### 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 I know there is a fork ability in ui, but it would be great if we could fork using a cli flag for better automation and tooling. Claude uses the following: ```bash --fork-session When resuming, create a new session ID instead of reusing the original (use with --resume or --continue) ``` e.g. ```bash opencode --continue --fork-session ``` or ```bash opencode --session [session_id] --fork-session ```
yindo added the discussion label 2026-02-16 18:08:44 -05:00
yindo closed this issue 2026-02-16 18:08:44 -05:00
yindo commented 2026-02-16 18:08:44 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 29, 2026):

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

  • #7978: feat(acp): add session/list, session/resume and session/fork support (CLOSED) - Already implemented ACP fork support programmatically
  • #8931: Feature: Expose TUI Session Management Commands via ACP (for Zed integration) - Proposes exposing fork and other session management commands through ACP for CLI/external client use
  • #7826: [FEATURE]: /branch command to create new session with compacted context - Related feature request for creating branches/forks of sessions with context

Feel free to ignore if this request is specifically about a direct CLI flag approach (--fork-session) rather than ACP or /branch command.

@github-actions[bot] commented on GitHub (Jan 29, 2026): This issue might be a duplicate of existing issues. Please check: - #7978: feat(acp): add session/list, session/resume and session/fork support (CLOSED) - Already implemented ACP fork support programmatically - #8931: Feature: Expose TUI Session Management Commands via ACP (for Zed integration) - Proposes exposing fork and other session management commands through ACP for CLI/external client use - #7826: [FEATURE]: /branch command to create new session with compacted context - Related feature request for creating branches/forks of sessions with context Feel free to ignore if this request is specifically about a direct CLI flag approach (--fork-session) rather than ACP or /branch command.
yindo commented 2026-02-16 18:08:44 -05:00
Author
Owner
Copy Link
Copy Source

@ariane-emory commented on GitHub (Jan 29, 2026):

Normally forking happens on a specific message within a session. Is your intent that it would automatically fork on the last/most-recent message in the session (i.e, using this on a session with one message in it would be equivalent to starting a new session)?

@ariane-emory commented on GitHub (Jan 29, 2026): Normally forking happens on a specific message within a session. Is your intent that it would automatically fork on the last/most-recent message in the session (i.e, using this on a session with one message in it would be equivalent to starting a new session)?
yindo commented 2026-02-16 18:08:45 -05:00
Author
Owner
Copy Link
Copy Source

@moonray commented on GitHub (Jan 29, 2026):

For CLI based forking, Claude Code's session behavior seems optimal to me, not forking before the last message.
https://code.claude.com/docs/en/how-claude-code-works#resume-or-fork-sessions

@moonray commented on GitHub (Jan 29, 2026): For CLI based forking, Claude Code's session behavior seems optimal to me, not forking before the last message. https://code.claude.com/docs/en/how-claude-code-works#resume-or-fork-sessions
yindo commented 2026-02-16 18:08:45 -05:00
Author
Owner
Copy Link
Copy Source

@ariane-emory commented on GitHub (Jan 29, 2026):

@moonray Well, alright... I do not use Claude Code, so I'm just trying to understand this from the documentation that you linked:

  1. The --fork-session switch essentially just duplicates the session in question and then loads that duplicate?
  2. Should we retain OpenCode's current behaviour of re-titling forked sessions to something like Some session (fork #1), even though we aren't truly 'forking' the session per se (but rather are simply duplicating it)? I would assume that that would be desirable, but I could be mistaken.
  3. This switch must be used in conjunction with --continue or --session, opencode --fork-session would be non-sensical?

If I am understanding your intent correctly, I could take a stab at this and see what I can cook up.

@ariane-emory commented on GitHub (Jan 29, 2026): @moonray Well, alright... I do not use Claude Code, so I'm just trying to understand this from the documentation that you linked: 1. The `--fork-session` switch essentially just duplicates the session in question and then loads that duplicate? 2. Should we retain OpenCode's current behaviour of re-titling forked sessions to something like `Some session (fork #1)`, even though we aren't truly 'forking' the session per se (but rather are simply duplicating it)? I would assume that that would be desirable, but I could be mistaken. 3. This switch _must_ be used in conjunction with `--continue` or `--session`, `opencode --fork-session` would be non-sensical? If I am understanding your intent correctly, I could take a stab at this and see what I can cook up.
yindo commented 2026-02-16 18:08:45 -05:00
Author
Owner
Copy Link
Copy Source

@moonray commented on GitHub (Jan 29, 2026):

  1. That is correct. It's still a fork, if you continue in both sessions, though. :)
  2. The current opencode titling makes the most sense
  3. Correct. You cannot fork without a session id, or you're simply creating a new session. --continue is simply shorthand for providing the last used session id. So it must be used in conjunction with either --continue or --session [session id]
@moonray commented on GitHub (Jan 29, 2026): 1. That is correct. It's still a fork, if you continue in both sessions, though. :) 2. The current opencode titling makes the most sense 3. Correct. You cannot fork without a session id, or you're simply creating a new session. `--continue` is simply shorthand for providing the last used session id. So it must be used in conjunction with either `--continue` or `--session [session id]`
yindo commented 2026-02-16 18:08:45 -05:00
Author
Owner
Copy Link
Copy Source

@ariane-emory commented on GitHub (Jan 30, 2026):

@moonray Alrighty then... I rolled the dice a few times, had a few different models try their out their own takes on this feature, then tossed them into the arena to let yet another set of models review these and assess the best amongst them. I've now submitted a PR for the take that was deemed the best of the bunch, which can be found here: #11340.

Fingers crossed that the maintainers will like it!

@ariane-emory commented on GitHub (Jan 30, 2026): @moonray Alrighty then... I rolled the dice a few times, had a few different models try their out their own takes on this feature, then tossed them into the arena to let yet another set of models review these and assess the best amongst them. I've now submitted a PR for the take that was deemed the best of the bunch, which can be found here: #11340. Fingers crossed that the maintainers will like it!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label discussion
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#7945
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?