Thread forks
Split a Tejus conversation from the whole thread or an exact turn while preserving source lineage and environment intent.
A fork creates a new thread from an existing Tejus thread. Use it when you want to explore another approach, preserve a useful point in the conversation, or continue the same context in a separate environment without changing the source thread.
Fork or new thread
Choose a fork when the new work needs the source transcript and its decisions. Create a normal new thread when the objective should start without inherited conversation context.
| Need | Better choice |
|---|---|
| Try another implementation from the same discussion | Fork |
| Continue from a specific completed turn | Fork from that turn |
| Give unrelated work a clean owner | New thread |
| Continue the same thread with another provider | Provider handoff |
| Ask a narrow question without creating a full branch of work | Side chat (/side) |
Fork the complete thread
Run /fork with an empty composer, or right-click the thread in the sidebar and open Fork. Tejus asks where the fork should run:
- Fork Into New Worktree creates a new worktree-backed thread based on the source thread’s branch. As with any new worktree thread, the worktree itself is created when you send the fork’s first message.
- Fork Into Local stays in the source thread’s current environment. If the source already runs in a worktree, local means that same worktree rather than the repository’s main checkout.
You can skip the question with /fork worktree or /fork local.
The source thread remains unchanged. The fork opens as a separate thread, with the same title, its own future turns, and its own delivery boundary.
Fork from one turn
On a finished assistant message, click the fork icon (Fork from here) in the message footer, next to Copy. The new thread imports the transcript only up to and including that message, so later experiments or corrections from the source do not enter the fork.
A footer fork always stays in the source thread’s current environment (the same as Fork Into Local). Use /fork worktree or the sidebar menu when you want a new worktree.
The fork shows a Continued from chat divider where its own work begins. Click it to open the source thread and verify exactly where the histories separated.
Choose the environment
Use a new worktree when both threads may edit files, when the fork is experimental, or when each result needs its own branch and pull request.
Stay local only when shared working-tree ownership is deliberate. Two active threads editing the same checkout can overwrite assumptions and make the final diff impossible to attribute.
Read Worktrees before running the source and fork as concurrent writers.
What Tejus preserves
A fork records its source thread and imported transcript boundary. It also carries the selected provider and model, runtime permission mode, interaction mode (for example Debug), and the source environment into creation.
The destination remains a distinct thread. Future messages, queued turns, goals, approvals, Git operations, and completion state belong to the thread where they occur. Inspect them rather than assuming the two threads remain synchronized.
Native and reconstructed forks
Tejus uses a provider-native session fork when the provider supports it and the source session is eligible. Native forking is implemented for Codex, Claude, Cursor, Droid, Grok, OpenCode, and Oh My Pi.
When a provider cannot fork natively, or the native fork fails, Tejus carries the retained transcript into the new thread instead. The visible lineage is the same in either case, but provider-private state may not transfer through the transcript.
When forking is unavailable
Forking needs an existing thread with at least one finished message. It is not offered for side chats or subagent threads, and /fork is only offered when the composer is empty and the thread is in normal mode (not Plan or Debug). The footer Fork from here action appears only on settled assistant messages.
If Tejus shows Fork is unavailable, wait for the relevant turn to settle, confirm the source thread and project still exist, and retry from the intended turn. Do not work around an unavailable fork by manually copying an unreviewed partial transcript into a shared checkout.
Verify a fork
After creation, confirm:
- The new thread links to the intended source and turn boundary.
- The provider, model, runtime mode, and interaction mode are correct.
- The environment is local or worktree-backed as intended.
- The branch and working directory match the new ownership boundary.
- Any persistent goal is explicitly appropriate for the fork.
- The final diff contains only work attributable to this thread.
Fork checklist
- A fork is more appropriate than a new thread or handoff
- The source turn is settled and correct
- Local versus new-worktree ownership is deliberate
- Source lineage appears in the new thread
- Provider and mode selections are correct
- Shared-checkout collision risk is understood
- The fork’s result is reviewed and delivered independently