feat(desktop): add message-level fork action

[adrian15]

Issue for this PR

Closes #25582

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Fork to new session option was not present at the OpenCode Desktop app.
So I have added back the option thanks to OpenCode itself and OpenAI ChatGPT 5.3 Codex.

Regarding understanding why the changes work, well, it's my first time dealing with the OpenCode codebase so I'm a bit lost here. However I will say that I have insisted that changes follow contribution guidelines and that it should reuse or recreate TUI based behaviour as much as possible so hopefully that has ended up in a better PR than a regular one-shot vibe-coded PR.

How did you verify your code works?

• Ran bun install from repo root.
• Ran bun run typecheck from repo root.
• Ran bun run typecheck from packages/app.
• Manually tested forking from user messages:
  • new forked session opens,
  • selected message content is restored in the new session prompt,
  • sidebar highlights the forked session,
  • failure fallback uses localized request-failed messaging.

Screenshots / recordings

The new Fork the new session option:

How a new forked session is seen:

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found one potentially related PR:

Related PR:

• feat: add message_click_actions tui config #25572 - feat: add message_click_actions tui config
  • This PR appears to be working on message-level click actions in the TUI, which is closely related to the fork action feature being added in PR feat(desktop): add message-level fork action #25584. They may be complementary changes addressing similar UI interaction patterns.

No duplicate PRs found that are addressing the exact same fork action feature.

[adrian15]

In addition to the regular template PR I will say that:

I have tested Electron-based OpenCode in Debian 13 GNU/Linux.
I have tested Tauri-v2-based OpenCode in Debian 13 GNU/Linux.

I have not tested neither Electron-based OpenCode nor Tauri-v2-based OpenCode in Windows / MacOS.

I have focused my testing on Electron-based OpenCode because someone said recently in one of issues that this was new beta beta App.

I also have a video that documents how I have developed the feature:
LLM Playground Live | Episode 6 just in case the screenshots are not good enough.

[adrian15]

Related PR:

• feat: add message_click_actions tui config #25572 - feat: add message_click_actions tui config

• This PR appears to be working on message-level click actions in the TUI, which is closely related to the fork action feature being added in PR feat(session): add message-level fork action #25584. They may be complementary changes addressing similar UI interaction patterns.

Well, for now I think I can ignore that PR. If that PR ever gets included onto OpenCode codebase I could revisit my own PR to check if that specific enable/disable switch should also trigger a different behaviour in the OpenCode Desktop (for now I don't think so) because in the Desktop there is no such a thing like a pop-up based on random clicks on the UI.

[adrian15]

Regarding how the Pull Request is supposed to be handled...

Am I supposed to click on the 'Update branch' button every time there are new changes in the dev branch?

I see that it creates additional merge commits.

I'm not sure if I should manually rebase stuff in my own branch and force-push it so that the latest commit is always 'clean' on top of the dev branch.

Or is it not needed at all and you will get rid of those Merge branch 'dev' into additional commits with a click in the Github UI while merging?

[adrian15]

As commented in the associated issue I have updated this PR so that the 'Fork to new session' is in the very left.

The button itself is working as expected. I have only tested the Electron Desktop Build myself because the old Tauri-v2 Desktop seems no longer to be packaged as the default desktop.

And, again, this has been only been tested in Debian 13 GNU/Linux.