[Feature]: conversation branching (fork thread from a message)

[AudricY]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

Not sure

Problem or use case

In Claude Code, you can branch a conversation from any message to explore a different direction without losing the original thread. This is useful when you want to try an alternative approach, test a different idea, or diverge from a plan mid-conversation.

t3code doesn't seem to currently support this.

Proposed solution

Inline action toolbar for responses with a branch icon button (extendable with more icon buttons for other future features).

Clicking on it creates a new thread under the same project seeded with all messages up to that point.

Original thread remains untouched.

Why this matters

Coding conversations are full of decision points . "Should I use approach A or B?", "let me try this refactor but I'm not sure it'll work", "wait, what if we solve it differently?" Right now, the only options are to continue in the same thread (losing the ability to go back cleanly) or manually start a new thread and re-explain context from scratch.

Branching lets you explore without commitment.

Smallest useful scope

NA

Alternatives considered

No response

Risks or tradeoffs

No response

Examples or references

chatgpt ui with inline action toolbar for model responses:

Contribution

• I would be open to helping implement this.

[Greyvend]

Claude desktop has this, it's pretty useful, especially in order to spawn one/several additional agents with the same context for further work (e.g., implement a specced feature, research subtopic within, explore different directions).

[Ben01233210]

Would be really nice if t3 code would have this

[renanmoretto]

+1 for this. Currently using t3 code but I miss this feature so much from Claude Code. Claude Code CLI has this as a /branch command.

[hwanseoc]

the codex app and CLI has this feature as well.

[vladknysh]

+1 for this

[juliusmarminge]

#2829

[vinogradgarden]

Any news on this?

[florensie]

It would also be nice to have Codex's side conversations, which are essentially just ephemeral forks, not visible in the sidebar as a new session. It's really useful during long-running tasks to ask for status updates, or just in general to ask questions without bloating the main context.

[LunarRed]

It would also be nice to have Codex's side conversations, which are essentially just ephemeral forks, not visible in the sidebar as a new session. It's really useful during long-running tasks to ask for status updates, or just in general to ask questions without bloating the main context.

Yes, please this but I also would like to fix Codex's implementation where they time out at some indeterminate future date and disappear. I don't need them to be permanent, but I also don't want them to vanish when I return from lunch or getting interrupted. Let me choose when to close/make them disappear.

[CopyJosh]

I didn't realize there was a PR for this in the works with a greater rewrite, before I made a fork that adds this functionality. Anyone else who wants to add this to their fork can play with pointing their agent here: https://github.com/beardwhocodes/t3code

[KaKi87]

I made a fork that adds this functionality

You say here : Cursor and Grok are hidden: their protocol describes fork support but neither CLI implements it

Would you please consider implementing it on the T3 side instead, i.e. duplicating the thread with a new ID and the same messages ?

I only have Cursor and am right now stuck with the official client because of the Fork Chat feature.

Thank you

[sprintthunder-dotcom]

I’d like to clarify a stronger version of the fork requirement that is important for safe experimentation:

A child fork should be isolated from its parent at both the conversation and filesystem levels.

Expected behavior

• Fork from a completed response/run and inherit the conversation context and code state at that point.
• Create the child on its own Git branch/worktree (or an equivalent isolated workspace), instead of reusing the parent’s current worktree.
• Changes made in the child must never modify or appear in the parent/main workspace automatically.
• The child can be discarded with zero effect on the parent.
• Moving work back must be an explicit user action: show the diff, require confirmation, then merge/cherry-pick/apply only the approved changes.
• Conversation/context merge-back should also be explicit; nothing should propagate into the parent automatically.

In plain terms: sub remains sub, main remains main. The child exists to test another idea. Nothing from the child reaches main unless the user explicitly reviews and approves a merge.

This matters because a conversation fork that shares the same Git worktree is not safe for parallel experiments: either side can mutate the other side’s code state. Please consider independent worktree allocation an explicit acceptance criterion. The desired model is:

conversation lineage fork + isolated Git branch/worktree + explicit merge gate.

[yaacovcorcos]

I have implemented and manually validated conversation forking in Scient, a downstream desktop application derived from T3.

This implementation does more than create a new empty thread. It currently supports:

• forking from a selected completed assistant response;
• server-authoritative resolution of that response into the durable conversation boundary;
• same-workspace forks, including projects without Git;
• an optional independent Git worktree when a suitable checkpoint exists;
• clear worktree eligibility when isolation is unavailable;
• inherited messages and attachment ownership;
• durable lineage and restart recovery;
• an immutable inherited transcript across subsequent turns, revert, and re-fork;
• provider-context bootstrap without counting inherited messages as new fork-local turns.

The working implementation and subsequent architectural cleanup are available here:

• Scient fork implementation
• Server-authoritative boundary cleanup
• Persistence and migration normalization

I understand that #2829 replaces the existing orchestration architecture, so I am not proposing to open a large competing V1 PR.

Would it be useful for us to compare these validated behaviors against the current #2829 implementation and contribute any missing pieces as small, focused PRs? In particular, we can help with same-workspace non-Git forks, independent-worktree eligibility, selected-response boundaries, attachment transfer, or revert/re-fork recovery—only where those remain genuine gaps.