Repository navigation
Feature: Visual Conversation Timeline for Navigation and Branching - aka 'Branch' #1020
Copy link
Copy link
Closed
Description
User Story
As a user, I want to view my conversation history as a visual graph so that I can easily understand the flow of my work, navigate between different conversational paths, and branch off from any point to explore alternative solutions using the keyboard in the TUI.
Acceptance Criteria
- A new "Timeline" view can be toggled on and off with a keybinding (example:
Alt+B). - The view renders all sessions for the current project as a graph or tree, showing parent-child relationships.
- The user can navigate the nodes of the graph using arrow keys (
Up/Down/Left/Right). - The currently selected node is visually highlighted.
- A tooltip or preview pane displays a summary of the user's prompt for the selected node.
- Pressing
Enteron a node switches the main chat view to that session's context and closes the timeline view. - Pressing
Shift+Enteron a node creates a new, empty session that is a child of the selected session, and immediately switches the TUI to this new session. Essentially branching the conversation from this point.
Proposed Design & Mockup
The visual layout should resemble a simple git style tree to feel familiar and intuitive in a terminal environment. The final design is open to discussion, but here is a proposed mockup:
┌─────────────────── Conversation Timeline ────────────────────┐
│ │
│ ●─ Implement user login .1 │
│ │ │
│ ●─ Create the backend API endpoint for login .2 │
│ │ │
│ ●─ Add basic validation to the API endpoint (current) .3 │
│ ├─● Branch A: Explore using Zod for validation │
│ │ │ │
│ │ ●─ Add Zod schema for login │
│ │ │
│ └─● Branch B: Explore using a different library │
│ │ │
│ ●─ Back to .3 before any branching │
│ │
└──────────────────────────────────────────────────────────────┘
Open Questions for Implementation:
- Layout Algorithm: The exact algorithm for drawing the tree is detable imo as idk which way to go tbh. A simple indented list is a good starting point.
- Tooltip Content: The preview tooltip should initially contain the user's prompt. This could be expanded later to include a snippet of the AI's response if useful (maybe?).
Implementation Details
This feature can be implemented by leveraging the existing parentID in the session data structure.
-
Backend (TypeScript -
packages/opencode):- No major changes are required. The backend already supports the necessary data structures and endpoints.
GET /session: Provides the list of all sessions withidandparentID.POST /session: TheSession.createfunction already accepts an optionalparentID, which is all that's needed for the branching functionality.
-
TUI (Go -
packages/tui):- New Component: Create a new
timelinecomponent inpackages/tui/internal/components/timeline/.- This component will be a
tea.Model. - It will receive the list of all project sessions and build an in-memory graph data structure (e.g., a map of
parentID -> []childSessions). - Its
View()method will be responsible for rendering the graph using box-drawing characters. - It will manage its own state, including the selected node, graph traversal logic, and viewport scrolling.
- This component will be a
- Main Model Integration (
tui.go):- The main app model will fetch all sessions and pass them to the timeline component.
- It will manage the timeline component as a modal, toggled by the new keybinding.
- It will handle messages from the timeline component, such as
SwitchSessionMsg{SessionID: "..."}andBranchSessionMsg{ParentID: "..."}.
- Keybinding (
commands.go):- Add a new command, e.g.,
TimelineViewCommand, with theAlt+Bkeybinding (or another suitable key).
- Add a new command, e.g.,
- New Component: Create a new
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels
Activity
Kirow commentedon Sep 4, 2025
Is there is a way to duplicate (clone/copy) session in current implementation?
I'd like to start different sessions from the context of current session. Similar to branches described above, but they should be isolated from each other (3 separate sessions -
root,Branch A,Branch B) - i.e.Branch Bshould not know about results fromBranch A.fix: harden codex sync CI hermeticity (anomalyco#1020)