Codex CLI Fork: Try Another Approach From a Saved Session

Use codex fork to start a new conversation from a saved Codex CLI session, or /fork from the current chat. The fork gives you another path to explore while preserving the original conversation, as described in the official OpenAI command reference↗ (opens in a new tab). It is useful when the problem is understood but you want to try a different solution.

The important follow-up is choosing which result becomes the project’s next step. fenbs keeps that handoff outside the conversation, so another assistant can find the chosen approach and its reason without reading both experiments.

How do you fork a saved Codex CLI session?

1. Open a terminal in the project you intend to work on. Check its current files and any unfinished edits before starting another experiment.
2. Run codex fork and choose the saved session. Use codex fork --all if the session is outside the current directory’s picker.
3. Use codex fork SESSION_ID when you know the exact session, replacing SESSION_ID with its identifier. Use codex fork --last only when the latest session is the one you mean.
4. Tell the new conversation which alternative to investigate, what must stay the same, and whether it should propose a plan before editing.

If you are already in the relevant conversation, enter /fork there. For other terminal actions, keep the Codex CLI commands guide nearby. Start the experiment with a small question you can answer, such as whether the existing helper can handle a new case without changing its public behavior.

What does the fork carry into the new conversation?

The fork carries the earlier conversation into a separate chat with a new identity. Think of it as another starting point for discussion, rather than a promise that every part of the development environment has been copied. Before relying on an earlier observation, ask Codex to check whether it still matches the files now available.

For example, a previous turn might say that a function has two callers. Another developer may have added a third since then. The old explanation helps locate the question, but current code answers it. The same applies to test results, running services, dependencies, and assumptions about a file that has moved.

Give the new session a short orientation: the experiment’s purpose, the relevant files, and the point at which its approach should differ. You do not need to paste the entire earlier discussion again. You do need to correct any assumption that has changed since it was recorded.

How is a fork different from resume or a Git branch?

Keep conversation separation and file separation as two explicit choices. A second chat can still work on the same files. If two experiments edit the same directory, the second may encounter the first experiment’s changes, making a fair comparison difficult.

OpenAI’s worktree documentation↗ (opens in a new tab) explains using separate checkouts for parallel work; a checkout is a working copy of repository files. The dedicated Codex CLI worktree guide covers that setup. For a discussion-only alternative, you can ask for a proposed patch or explanation before allowing file changes.

What should you ask the alternative session to do?

Change one important variable at a time. If the original approach adds a dependency, ask the fork to attempt the same outcome using the project’s existing tools. If the original changes a shared component, ask whether a narrower change solves the same problem. Keep the acceptance criteria identical.

Explore an alternative to the previous plan.
Goal: fix the empty-state error without changing the public API.
Constraint: use existing dependencies.
First inspect the current files and summarize the proposed difference.
Do not edit until the comparison is clear.
Explain what checks would distinguish the two approaches.

Avoid asking only for something “better.” Say whether you care about fewer changed files, clearer error handling, less operational work, or easier reversal. An answer that meets a different goal can sound impressive while being useless for your decision. The Codex CLI best practices guide covers setting clear tasks and reviewing their results.

How do you compare the two outcomes fairly?

Compare the resulting behavior and evidence. A confident final message is not a test result. For each approach, record the starting code state, what changed, which checks actually ran, and what remains uncertain. If the starting states differ, resolve that before treating a performance or correctness difference as meaningful.

• Correctness: does the implementation meet the same acceptance criteria, including the failure case?
• Scope: does it change only the necessary behavior, or introduce unrelated edits?
• Maintenance: can another developer understand why this approach was chosen?
• Verification: are the checks relevant, and are failures or skipped checks clearly stated?

OpenAI documents a code review workflow↗ (opens in a new tab) for inspecting changes. Use a review as another source of findings, then assess those findings and run the project’s appropriate checks. Preserve the human choice and the remaining work in fenbs’s shared work record, especially when neither alternative is ready to call finished.

What should you check when the fork looks wrong?

First check that you chose the intended session and project directory. Then compare the actual files with the assumptions in the conversation. A mismatch may come from selecting a different session, returning after someone else changed the code, or allowing two experiments to edit the same working copy.

Pause editing while you identify the mismatch. Ask for a summary of the current files and the proposed next action, then decide whether to keep this experiment. Do not use a conversation fork as a way to undo file changes; inspect and recover the files through your normal version-control process.

How to do this with fenbs

1. Create a free account, add the project, and create a task describing the problem and its acceptance criteria.
2. Connect Codex CLI using the integration guide, and ask it to read the project’s AI context before the experiment.
3. After comparing the approaches, have the assistant record what you chose and why in Decisions and rules. Keep unchosen proposals distinct from your decision.
4. Save the task’s progress and Where we left off, including the chosen approach, relevant files, checks performed, and the next unresolved step.

fenbs does not fork Codex conversations, copy repository files, or import chat transcripts. It is not the right fit if all you need is a second local conversation. It helps when the outcome must survive a change of assistant or teammate; the AI handoffs collection covers that wider workflow.