Feature proposal: branch from an older assistant response

[mkiiim]

Feature proposal: branch from an older assistant response

Have you ever been deep into a Codex session and realized that the best path forward diverged from something the assistant said much earlier? Not from the current point in the conversation, but from an earlier response before the session drifted in another direction.

The current /fork command is useful, but it branches from the present. There is no way to say “branch from that earlier assistant response and explore a different path from there.” The workaround is to scroll back, copy context, start a new session, and manually reconstruct the state. That is lossy and interrupts the workflow.

Proposal

Add line branching: the ability to select a previous assistant response in the active session and create a child thread anchored to that response.

The parent session remains intact, the child branch carries forward the conversation context up to the selected assistant response, and the user can return to the parent thread.

Possible user-facing surface:

• /branch-from <snippet>: select a previous assistant response by text match and branch from it
• /return: return from a child branch to its parent thread
• /branch-info: inspect the current branch context
• /branch-list: list and navigate branches for the current conversation

Session continuity

For this to work well, the branch should persist enough provenance to make resumed sessions understandable:

• Which parent thread the branch came from
• Which assistant response was used as the anchor
• A short summary/snippet of the anchor context
• Branch depth and child/parent relationships
• Inline markers in parent transcripts showing where child branches were created

This makes branch state visible after resume, not just during the original interactive session.

Why this matters

The highest-value moments in a Codex session are often pivots: points where a different approach becomes worth exploring. Today those pivots require either abandoning the current thread or manually reconstructing context elsewhere.

For example, suppose you are 20 messages into designing an API. Early in the session, Codex suggested two viable interface designs and you chose one. Several refactor cycles later, you want to revisit the other. With branching, you could branch from that earlier assistant response, explore the alternative with the correct prior context intact, then return to the main line.

That changes the cost of exploration. Instead of hesitating to try a path because it may disrupt the current session, users can branch, explore, and return.

I’m interested in whether this fits the team’s direction, and whether this is a feature area maintainers would want to see developed further.