Option to edit an earlier prompt in place instead of always forking (config toggle and/or per-edit prompt)

[Yan233th]

What variant of Codex are you using?

CLI

What feature would you like to see?

Since 0.145.0 (#33201), editing an earlier prompt always creates a fork/branch. I'd like the ability to choose between forking and editing in place.

1. A config toggle (e.g. in config.toml):

[tui]
edit_earlier_prompt_mode = "fork"   # "fork" | "in_place" | "ask"

• fork — current behavior (branch, preserve original). Keep as default.
• in_place — edit the message in the current session without creating a new one.
• ask — prompt at edit time (see below).

2. An interactive prompt when confirming an edit: after Esc-Esc → TRANSCRIPT → select a message → press Enter to edit, show a choice:

Editing an earlier message:
  [Fork]          Create a new branched session (preserves original)
  [Edit in place] Modify in the current session

I'm not asking to revert #33201 — preserving history on fork is good. Just make it a configurable default rather than the only option.

Additional information

Motivation — the always-fork default has real costs for workflows that just want to fix a typo or rephrase a previous prompt without spawning a new session:

• Timestamp provenance: the forked branch loses the original per-message timeline — I reported this separately in Forked session loses all original record timestamps when editing an earlier prompt (codex-cli 0.145.0) #35003; an in-place mode would avoid it entirely.
• Session proliferation: each edit creates a full-copy session file (~23MB each on my sessions); one editing session produced 8 forks / ~190MB.
• No opt-out: users coming from 0.144.0 (where editing overwrote — see Esc-Esc “fork from earlier message” overwrites original session instead of preserving resumable branch #31902) now get the opposite behavior with no way to choose.

Related: #33201 (the change), #35003 (timestamp side effect), #31902 (prior overwrite complaint — the pendulum this would balance).

The config key name is just a suggestion; happy with whatever fits the existing schema.

[escape0707]

+1, the new behavior is unbearably slow and space consuming, even though I understand this feature is to prevent losing conversation by accident/mis operation. I have to roll back to 0.144.

Maybe don't truncate the conversation on user viewing transcript and hitting Enter for the first time, but only truncate when they input different message at that previous location and hit enter to submit edited message?

[12113004]

Confirmed on Codex CLI 0.145.0.

Environment:

• Linux x86_64
• tmux 3.5
• Model: gpt-5.6-sol

I originally encountered this while launching Codex through oh-my-codex, but confirmed that OMX is not responsible for creating the new session.

The behavior changed inside Codex itself:

• In rust-v0.144.4, Esc-Esc backtrack submitted an in-place thread rollback.
• In rust-v0.145.0, the same flow dispatches ForkSessionForPromptEdit, creating a new session before restoring the selected prompt.

For small corrections or prompt rewording, always creating a fork causes unnecessary session proliferation. I would strongly prefer either an in_place mode or an ask mode. Explicit /fork can remain available when preserving the
original branch is desired.

[stoodfarback]

Additional motivation: the new fork has a different session id, and currently that means a different prompt_cache_key. Unquantified, but it feels like that may cause more cache misses.

[zimtsui]

Why not add a new shortcut (e.g. Ctrl+f) to fork in the message selection.