hermes - 💡(How to fix) Fix [Feature]: Branch/fork a session from a specific message

Problem or Use Case

Hermes already has /branch / /fork, but it branches from the current session state only. There is no first-class way to fork a session from a specific earlier message/turn.

The workflow I want is:

I'm reading a long chat, spot a specific message where the conversation could have gone a different direction, and want to fork from exactly there without manually reconstructing context or undoing later turns.

This came up while discussing how /branch works today. The existing behavior is useful, but for long-running sessions it would be much more ergonomic to branch from a selected message.

Related but distinct: #31233 proposes /split to branch into a new terminal window while keeping the parent open. This issue is about the branch point: choosing the exact message/turn to branch from. These two features could compose later.

Proposed Solution

Add support for creating a branch from a specific transcript message.

Possible UX shapes:

Gateway / messaging platforms

• If the user replies to a previous message with /branch <name> or /fork <name>, create the new branch using the transcript up to the replied-to message.
• If there is no reply target, keep today's behavior: branch from current session state.

Example in Telegram/Discord/Slack:

(reply to an earlier Hermes/user message)
/branch alternate-approach

Expected result:

• A new session is created with parent_session_id pointing to the original session.
• The branch transcript includes messages only up to the selected branch point.
• The current platform/session switches to the new branch, matching existing /branch semantics, unless a future /split-style flow is used.

CLI

Add an explicit target argument, for example one of:

/branch --at <message_id> <name>
/branch --at <turn_index> <name>
/branch --from <message_id> <name>

Existing behavior remains unchanged:

/branch <name>

continues to branch from current state.

TUI

This is the main open question for me.

Ideally, in the TUI I would love to be able to right-click a message and choose something like:

Fork from here
Branch from this message
Split from here

I am not sure whether that is technically possible in the current Ink / terminal UI stack, or whether terminal right-click events are too inconsistent across terminals.

If right-click is not practical, alternatives might be:

• keyboard-select a message in scrollback, then run branch from selected
• show stable message/turn numbers in TUI scrollback and support /branch --at <n>
• add a command palette action bound to the currently highlighted message
• support only the slash-command form first, then add richer TUI affordances later

Explicit Questions for Maintainers

1. Is this feature direction welcome?

   • Branching from current state exists; is branching from an earlier message considered a good fit for core Hermes?

2. What should be the canonical branch target?

   • Internal SQLite message_id?
   • A per-session turn index visible to users?
   • Platform native message IDs (Telegram/Discord/Slack message IDs)?
   • Some normalized Hermes transcript message identifier?

3. What exactly should be included in the copied transcript?

   • Up to and including the selected message?
   • If selecting an assistant message with tool calls, include the associated tool call/result messages?
   • If selecting a tool result, should that be allowed or normalized to the surrounding assistant turn?
   • If selecting a user message, should the branch stop before the following assistant response, or include it if it already exists?

4. Gateway behavior: should reply-to imply branch point?

   • If a Telegram/Discord/Slack user replies to an old message with /branch <name>, should that be interpreted as “branch from the replied-to message”?
   • What should happen if the platform message cannot be mapped back to a stored transcript entry?
   • Should it fall back to current-state branch, or return an explicit “could not resolve replied message” error?

5. TUI behavior: is right-click feasible/desirable?

   • Can the current TUI reliably detect right-click/context-menu events on a message?
   • Would maintainers prefer a keyboard-first interaction instead?
   • Should TUI expose message IDs/turn numbers to make slash-command targeting easier?
   • Is this better deferred until there is a more formal message selection model in the TUI?

6. CLI UX preference?

   • /branch --at <id> <name>?
   • /branch --from <id> <name>?
   • /branch <name> --at <id>?
   • Separate command like /branch-from <id> <name>?

7. Relationship to /split (#31233):

   • Should this be implemented independently first?
   • Should a future /split accept the same target selector, e.g. /split --at <id>?
   • In TUI, should “right-click → fork from here” open in-place or split/open a new view/window?

8. Session lineage / metadata:

   • Should the branch store extra metadata like branch_from_message_id, branch_from_turn, or branch_from_platform_message_id?
   • Would this be useful for future UI visualization of session trees?

9. Testing expectations:

   • Should tests focus on the shared transcript-slicing helper and then separately cover CLI/gateway/TUI integration?
   • Are there existing session DB fixtures/helpers maintainers prefer for this?

Alternatives Considered

1. Use /undo repeatedly, then /branch.

   • Works only in simple cases.
   • Destructive/inconvenient.
   • Bad UX for long chats.

2. Manually create a new session by copying transcript rows in SQLite.

   • Technically possible.
   • Not discoverable or safe for normal users.

3. Only support CLI message IDs.

   • Easier implementation, but misses the most natural gateway workflow: replying to a specific message.

4. Only support gateway reply-to.

   • Nice for Telegram/Discord/Slack, but leaves CLI/TUI users without a clean path.

5. Wait for /split and solve both together.

   • These are related but separable: /split is about where the new branch opens; this issue is about where the branch starts.

Suggested Implementation Sketch

A small shared helper could probably do most of the work:

create_branch_session(
    parent_session_id: str,
    branch_name: str | None,
    *,
    branch_until_message_id: int | None = None,
    branch_until_turn_index: int | None = None,
) -> BranchResult

It would:

1. Load parent transcript from SessionDB.
2. Resolve the branch target to a transcript slice boundary.
3. Copy only the selected prefix into the new session.
4. Preserve parent_session_id.
5. Optionally store branch-point metadata if maintainers want it.

Then wire it into:

• CLI /branch parser for --at / --from.
• Gateway /branch handler using reply_to_message_id when present.
• TUI later, depending on what interaction model maintainers prefer.

Feature Type

• CLI improvement
• Gateway / messaging improvement
• TUI improvement
• Session management / UX

Scope

Likely medium if limited to CLI + gateway transcript slicing, and larger if TUI right-click/context-menu support is included in the first PR.

My instinct would be to land this incrementally:

1. Shared branch-from-message/session slicing helper + tests.
2. CLI support with explicit --at or --from.
3. Gateway reply-to support.
4. TUI affordance once maintainers decide whether right-click/selection is feasible.

Contribution

I'd like to implement this myself and submit a PR, pending maintainer guidance on the UX questions above—especially the TUI interaction model.