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

Open 💬 8 comments Opened Jul 23, 2026 by 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 #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 #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.

View original on GitHub ↗

8 Comments

escape0707 · 1 month ago

+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 · 1 month ago

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 · 1 month ago

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 · 1 month ago

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

JC-S · 16 days ago

I hope this issue can be fixed as soon as possible. I have been maintaining a downstream patch as a workaround, but this does not seem like a sustainable long-term solution.

PurpleSwords · 5 days ago

The current version is terrible, so I've decided to roll back. If I want to create a new branch, I'll use fork. Having my chat list flooded with nearly identical conversations just because I rolled back for a couple of quick questions is completely ridiculous. I have to check subtle differences one by one just to figure out which conversation I actually need to keep. Besides, if I remember correctly, the memory feature extracts information from past chats, which in my view completely breaks the memory system. What a complete mess.

allentc · 2 days ago

I'm surprised this has been going on as long as it has. I'm tracking releases of codex cli, but I'm holding back upgrading others on the team, because I don't need them hitting this. The worst problem for me has been "codex resume some-session-by-name-not-uuid" can end up in one of the earlier forks that have the same name, which appears to the user as "codex lost thread!"

I don't know why codex needs to fork to edit a previous prompt. Perhaps there are good reasons for this. If that's the case, then resuming a session by name (as opposed to uuid) needs to ensure that the most recent fork having that name is the outcome.

Yoskaldyr · 58 minutes ago

I've decided to roll back also.
Proper Esc-Esc handling was one of the main features of cli version of codex (GUI doesn't have it at all). And now it's gone.