TUI resume fails: list_turns is not supported yet

I could not reproduce this on macOS arm64 with codex-cli 0.147.0-alpha.6.5 bundled with ChatGPT.

Both a new session resumed successfully by explicit ID and through the resume picker. thread_history_1.sqlite is also missing locally, so its absence alone does not appear to trigger the error.

This may be specific to Linux 0.147.0, older sessions, or an app-server version mismatch.

I've hit this just now and I cannot resume a single codex session locally :(

I'm on macos arm64 with 0.147.0 installed from brew

I can confirm this on Linux x86_64 with codex-cli 0.147.0 installed via npm.

The explicit-ID resume command fails with the same error:

codex -p openai resume <session-id>
Error: Failed to resume session from ~/.codex/sessions/.../rollout-....jsonl: thread/resume failed during TUI bootstrap: thread/resume failed: list_turns is not supported yet (code -32601)

Retrying with unified exec disabled produces the identical failure:

codex -p openai --disable unified_exec resume <session-id>

I also checked the saved rollout metadata: it was created by codex-cli 0.147.0, has source: cli / originator: codex-tui / model_provider: openai, and ends normally with task_complete. The rollout file is still present. This suggests the failure is not caused by a missing rollout, an obviously incomplete session, or the unified_exec feature flag.

I have omitted the session ID and rollout contents because they contain private conversation and tool-output data.

I can confirm same issue on x86_64 GNU/Linux
workaround that worked for me:
codex exec resume <session-id> "Continue from where we left off. First summarize the current state."

Hi @mvillmow, the frozen history/resume behavior you described is one of the persistence patterns I've been studying. Codex Rescue Alpha5 includes a read-only projection consistency check that compares canonical rollout progress against stored projection cursors without touching SQLite.

If you still have the affected pre-repair session locally, you can test it with:

pip install codex-rescue==0.1.0a5
codex-rescue doctor --latest --json

(or point doctor directly to the rollout file). Please sanitize/redact any sensitive paths or names before sharing diagnostic output; raw session files are never needed.

Code shape on main @ 1f41cc5d92 that explains the "some can, some can't" pattern: list_turns is implemented by the local thread store (thread-store/src/local/mod.rs#L542-L545); the list_turns is not supported yet error is the default trait impl (store.rs#L273-L280), which only fires when the serving process's store doesn't override it — i.e. the process handling your thread/resume is running code (or a store variant) without the implementation.

The most likely everyday cause is mixed versions between the TUI and a persistent app-server daemon: the TUI hands thread/resume to a long-lived background codex app-server, and that daemon keeps executing the binary it started with even after an npm/standalone upgrade replaces the CLI on disk (the same version-skew aggravator documented in #38792 — the daemon ran a deleted 0.146.1 binary for two days). A new TUI whose resume path requires list_turns against an old daemon that predates it yields exactly -32601 … not supported yet for every session, which matches @alexr17's "cannot resume a single session" onset.

Quick check/workaround: codex doctor shows the running app-server's version next to the CLI's — if they differ, kill/restart the daemon (codex app-server daemon stop or terminate the process) and resume again. Durable fix: a version/capability handshake at TUI↔daemon connect that refuses skew with "app-server is running version X, CLI is Y — restart the background server", instead of surfacing a bare method-not-found mid-resume.

Still reproducible on Windows with the current npm release:

• Codex: codex-cli 0.149.1
• OS: Windows 10 Pro x64 (10.0.19045)
• App server: local invocation (codex resume ... without --remote)

Resuming a local TUI session whose rollout metadata uses history_mode: "paginated" fails with the exact same error:

Failed to resume session from C:\Users\<user>\.codex\sessions\...\rollout-....jsonl:
thread/resume failed during TUI bootstrap:
thread/resume failed: list_turns is not supported yet (code -32601)

The rollout JSONL is still present and parses successfully. I reproduced the same list_turns failure on 0.145.0, 0.146.1, and 0.149.1. The affected session resumes successfully with 0.142.5, which suggests a regression or compatibility problem in the paginated-history/app-server resume path rather than a damaged rollout file.