Skip to content

Feature: /fork to open parallel session seeded with current context #8482

Closed as duplicate

Description

@its-DeFine

Problem

When I’m working in a Codex CLI chat session (session A), I frequently get an idea or uncover a related sub-problem that I want to explore in parallel (session B) without interrupting my current flow.

In these cases, Codex needs the context from session A to be effective in session B (the codebase state, decisions already made, constraints, errors seen, etc.).

Current workaround

Start a new Codex instance and manually pass the session ID of session A to seed context (e.g., using the resume/session-id flow). This is non-obvious, breaks momentum, and makes parallel work feel clunky.

Feature request

Add a first-class way to “fork” the current session into a new parallel session that automatically inherits the relevant context from session A.

Proposed UX

  • /fork → open a new parallel Codex session seeded with the current session’s context/history
  • Optional flags (examples):
    • /fork --title "Investigate alternative fix"
    • /fork --summary (seed with an auto-summary instead of full transcript)
    • /fork --last N (seed with last N turns)
    • /fork --fresh (open parallel session without seeding)

The command should print the new session ID and a clear hint for switching/attaching.

Expected behavior

  • The forked session starts immediately with inherited context (configurable: full transcript vs summary/last-N).
  • Both sessions proceed independently after the fork.
  • Discoverable via help/docs.

Why this matters

This would significantly improve UX for multitasking and exploratory workflows (debugging, “what if” investigations, docs, refactors) while keeping Codex effective by preserving the context it needs.

Activity

  1. etraut-openai commented on Dec 23, 2025

    @etraut-openai
    Contributor

    Thanks for the suggestion. We're already tracking this feature request in #4690, which has already received many upvotes. Rather than dilute future upvotes, I'm going to close this in favor of #4690.

    I like your proposed formulation and design. Perhaps you'd be willing to post to the existing feature request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions