CLI 0.147.0: Esc-Esc backtrack cannot find selected prompt in persisted thread

Resolved 💬 8 comments Opened Aug 7, 2026 by PaulRBerg Closed Aug 8, 2026

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.147.0

What subscription do you have?

Max

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Darwin 25.5.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

iTerm2 3.6.11

What issue are you seeing?

With an empty composer, using the Esc-Esc backtrack flow to select an earlier user prompt fails instead of creating a branch. Codex restores the selected prompt to the composer and shows:

Failed to branch before the selected prompt: the selected prompt was not found in the persisted thread

The selected prompt is visible in the transcript overlay, so the displayed history and the persisted thread used by the fork operation appear to be out of sync.

What steps can reproduce the bug?

Start or resume an interactive Codex CLI session with multiple completed user prompts.
Leave the composer empty.
Press Esc twice to open the transcript/backtrack overlay.
Navigate to an earlier user prompt and press Enter to edit it.
Observe the error.

Feedback was uploaded for the affected session: 019fdb75-1839-73d1-b40a-939a7e228e93.

What is the expected behavior?

Codex should branch before the selected prompt and restore that prompt to the composer for editing. Any prompt displayed as a selectable backtrack target should resolve in the persisted thread.

Additional information

This was observed on the 0.147.0 release, which introduced paginated TUI transcript history. The full codex doctor --json output is intentionally omitted because it contains unrelated local session paths.

View original on GitHub ↗

8 Comments

PaulRBerg · 20 days ago

this is definitely a regression in v0.147.0, it wasn't happening before

jancellor · 19 days ago

Also reproducing on codex-cli 0.147.0. An additional deterministic-looking case is:

Submit a prompt.
Press Esc while the turn is still running to cancel it, whether after some tool calls or not.
Use Esc-Esc to select and edit that just-aborted prompt.
The rollout JSONL confirms that the prompt and completed tool-call activity were persisted, followed by turn_aborted.

The prompt text is restored, but Codex reports:

Failed to branch before the selected prompt: the selected prompt was not found in the persisted thread

Submitting the edited prompt does not create a fork; it is appended to the original rollout, leaving the cancelled prompt in the thread history.

Speculation from my AI agent: this may be related to the paginated-history prompt-edit path introduced in #36950. The selected prompt exists in the transcript and persisted rollout, but appears not to be reconciled with the in-memory turn store used for the branch lookup after turn_aborted.

Uploaded the affected thread: 019fe145-4201-7a51-9214-cab11228ad52. Environment: Ubuntu 24.04.4 LTS, GNOME Terminal 3.52.0 (VTE 0.76.0).

etraut-openai contributor · 19 days ago

Thanks for the bug report. It was introduced when we recently added support for "paginated threads" which improve performance, memory overhead, and resume times for long sessions. It will be fixed in the next release. Apologies for the regression.

bendavis78 · 16 days ago

@etraut-openai Is there a workaround in the meantime? I'm still seeing this issue.

r0ck37c0d3r · 15 days ago

not fixed, still present in latest release, please reopen

PaulRBerg · 15 days ago

Is there a workaround in the meantime?

Nope. You can proactively use /btw until they fix this.

etraut-openai contributor · 14 days ago

This will be fixed in the next production release 0.148.0. If you want to verify in the pre-release, you can install 0.148.0-alpha.12.

wangtz0607 · 2 days ago

The issue is still present in v0.149.1. Please reopen. @etraut-openai