TUI resume fails: list_turns is not supported yet

Summary

Codex CLI cannot resume an existing local TUI session because thread/resume calls an unsupported list_turns method during TUI bootstrap.

Environment

Codex: codex-cli 0.147.0
OS: Linux x86_64 (kernel 5.15)

Steps to reproduce

Have an existing Codex TUI session under ~/.codex/sessions/.
Run codex resume <session-id> or select the session from the resume picker.
Observe that the TUI fails during bootstrap instead of opening the session.

Actual behavior

Failed to resume session from ~/.codex/sessions/YYYY/MM/DD/rollout-....jsonl:
thread/resume failed during TUI bootstrap:
thread/resume failed: list_turns is not supported yet (code -32601)

The local rollout file is still present.

Expected behavior

The CLI should resume the existing session successfully. If the stored session or active app-server protocol is incompatible, Codex should either use a compatible resume path or report a specific actionable version/protocol mismatch instead of invoking an unsupported method.

Additional information

A search of existing openai/codex issues for list_turns and the exact error text returned no matches. The rollout is not attached because it contains private conversation data, but sanitized diagnostics can be provided if needed.

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 "Continue from where we left off. First summarize the current state."

@mvillmow

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.

@alexr17

Code shape on main @ 1f41cc5 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.

Audited the current main and implemented a focused fork fix in PR #8. list_turns is implemented by the local thread store; the reported -32601 comes from the unsupported/default store path. Since persistent app-server connections already receive server version during initialize, the TUI now rejects a mismatched server version before entering thread/resume and gives an actionable daemon-restart message. Added unit coverage for equal, absent, and mismatched versions. This does not claim that all version mismatches are semantically incompatible; it is a fail-safe guard against the observed persistent-daemon skew. Fork PR: fscfede-beep#8.

Follow-up audit: fork PR #8 is intentionally narrow (2 files, 47 additions) and applies the version-skew guard at TUI connection time, before thread/resume. Base openai/codex CI on commit d648947 already shows pre-existing failures in SDK, Codespell, repo-checks, and some Bazel clippy jobs, while many Bazel test/release jobs pass; therefore those failures are not useful evidence against this two-file TUI patch. The fork PR has no maintainer review yet and its CI remains queued. The guard compares exact client/server versions as a fail-safe; a semantic capability negotiation could be a better long-term design if maintainers want compatibility across non-identical but wire-compatible versions.

Additional audit result: the exact-version guard is intentionally scoped to LocalDaemon connections. We rejected the initial broader guard because explicit Remote app-server endpoints may be intentionally version-skewed while remaining wire-compatible. Current fork PR #8 is 2 files / 55 additions and is mergeable. Its blocking-ci run is pending; the same upstream baseline already exhibited unrelated SDK/Codespell/repo-checks/Bazel-clippy failures, so those must not be attributed to this patch. Fork CI has not yet produced a certifying pass.

Audit checkpoint 2026-09-08: PR #8 remains mergeable. The version guard is now scoped only to LocalDaemon; explicit Remote endpoints are not blocked. Base OpenAI CI already had unrelated failures, while fork CI for the patch remains pending/queued. No CI pass or upstream merge is claimed. The patch therefore remains ready for maintainer review, with capability negotiation noted as the longer-term alternative to exact-version matching.

Latest checkpoint: the fork PR #8 remains mergeable at HEAD 45283d0. Its blocking-ci is still queued/pending and v8-canary remains active. No new maintainer feedback or contradictory issue evidence appeared, so I am not changing the patch speculatively. The current implementation remains LocalDaemon-only version-skew preflight with explicit Remote connections left untouched; exact-version matching is documented as a conservative guard, with capability negotiation as the longer-term option.

New CI evidence: the fork PR's Codespell failure is the pre-existing codex-rs/exec-server/src/no_follow/unix.rs:130: WRONLY ==> WRONGLY, and the exact same error occurs on the upstream baseline. The fork repo-checks / build-test failure is also the same workspace-manifest inheritance check already failing on that baseline. These are therefore baseline failures, not regressions from our two-file TUI patch. v8-canary is successful. Blocking CI remains red/pending because of baseline noise and other jobs; no patch-caused failure has been demonstrated. I am leaving the implementation unchanged and have recorded the evidence in RUMBO.

Root-cause follow-up is now implemented in fork PR #9: when a local rollout exists but its SQLite thread metadata is missing, paginated list_turns no longer immediately returns Unsupported. It invokes the existing targeted rollout migration for that thread, re-reads metadata, and proceeds when migration succeeds. A regression test covers a rollout present on disk with missing SQLite metadata. This directly addresses the observed list_turns is not supported yet boundary and is stronger than the earlier version-skew-only guard. Fork PR: fscfede-beep#9.

Root-cause validation is now on fork PR #9. The failure boundary is LocalThreadStore::validate_thread_for_paginated_reads: if SQLite lacks metadata for a thread, list_turns returned Unsupported even when the rollout file existed. PR #9 invokes the existing targeted migration for only the requested thread, re-reads metadata, and proceeds when migration succeeds; otherwise it preserves the original fail-closed behavior. A focused regression covers the missing-metadata case. PR #9 is mergeable. CI run 34214772055 is pending, with SDK failures already present before any thread-store change; no patch-specific CI failure has been established yet.

Audit correction on fork PR #9: the first self-healing implementation was circular because migrate_one_rollout itself rejects missing SQLite metadata. I corrected it. The current PR now reconstructs the missing SQLite row directly from the rollout's canonical SessionMeta via codex_rollout::extract_metadata_from_rollout, upserts it, then retries list_turns. The focused regression remains. This removes the circular dependency while preserving fail-closed behavior if no rollout can be resolved.

I reproduced this on Codex 0.160.1 when a paginated thread had a saved rollout header but had not started its first turn. thread/resume requested history cursors and returned list_turns is not supported yet because the state database had no thread metadata row yet.

A tested patch is available at philipgraffshapiro/codex@main...fix/turnless-paginated-resume-upstream (commit a942995). It allows empty cursor reads only after checking that the saved rollout belongs to the requested thread, uses paginated history, parses cleanly, and has no turn start or completion event. Legacy and populated histories keep their existing validation.

The two new app-server regressions pass on current upstream main (14c8b77), and its thread-store suite passes 268/268. I also installed the 0.160.1 build locally and verified a fresh turnless paginated thread/resume returns empty turns and cursors.

GitHub's compare page says only repository collaborators can open PRs here, so I could not submit this branch as a PR.

Related observation on Codex 0.162.1, Linux, using a custom app-server client alongside the native remote TUI.

A newly created thread had history_mode: paginated. Our secondary client discovered the loaded thread using thread/loaded/list, then sent:

{"method":"thread/resume","params":{"threadId":"<redacted-thread-id>"}}

The server returned:

{"code":-32601,"message":"list_turns is not supported yet"}

The failure occurred around submission of the first user turn. The header was already saved; we cannot prove the state database contents at that instant or the exact first-write ordering. This resembles the turnless-paginated case reported in the October 8 comment, but we have not yet reproduced it independently of our integration.

Our adapter then terminated the foreground TUI and app-server because it treated this secondary attach failure as fatal. That teardown is our own integration defect, not evidence of an app-server process crash. We have reproduced our fatal handling with mocked processes and are tracking it separately.

Is thread/resume expected to succeed for an already-loaded paginated thread whose first turn is just starting? Does the October 8 turnless-thread fix cover this path, including default full-history and excludeTurns: true cursor loading?

No private transcript, credentials, account identifiers, thread identifiers, or local filesystem paths are included.

This comment was automatically generated by GPT-6.1-sol with xhigh reasoning and posted at the user's direction.

Navigation Menu

Repository navigation

TUI resume fails: list_turns is not supported yet #37754

Summary

Environment

Steps to reproduce

Actual behavior

Expected behavior

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

TUI resume fails: list_turns is not supported yet #37754

Description

Summary

Environment

Steps to reproduce

Actual behavior

Expected behavior

Additional information

Activity

wWzZb commented on Aug 10, 2026

alexr17 commented on Aug 10, 2026

lirundong commented on Aug 11, 2026

emuntean-godaddy commented on Aug 17, 2026

boombx403-byte commented on Aug 18, 2026

jdcodes1 commented on Aug 18, 2026

karolzlot commented on Aug 24, 2026

fscfede-beep commented on Sep 8, 2026

fscfede-beep commented on Sep 8, 2026

fscfede-beep commented on Sep 8, 2026

fscfede-beep commented on Sep 8, 2026

fscfede-beep commented on Sep 8, 2026

fscfede-beep commented on Sep 8, 2026

fscfede-beep commented on Sep 8, 2026

fscfede-beep commented on Sep 8, 2026

fscfede-beep commented on Sep 8, 2026

philipgraffshapiro commented on Oct 8, 2026

lazyckc commented on Oct 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions