Codex thread/resume fails with list_turns is not supported yet when continuing a desktop thread on Android #12462

Activity

1. juliusmarminge commented on Sep 18, 2026

   

   juliusmarminge

   on Sep 18, 2026

   Member

   More actions

   Triage

   Confirmed bug. Continuing a Codex thread from Android after it was used on desktop fails because T3’s thread/resume is rejected by the Codex app-server with:

   list_turns is not supported yet (JSON-RPC -32601)

   That becomes ProviderAdapterProcessError (codex) from startSession via ensureSessionForThread / processTurnStartRequested. The thread then fails on every send.

   T3 never calls list_turns. Codex’s thread/resume does, internally. This is the same upstream failure as openai/codex#37754 (open): the serving store hits the default list_turns impl (not supported yet), commonly from app-server/store version skew, paginated history, or missing SQLite thread metadata even when the rollout file is still present.

   Where it breaks

   • apps/server/src/provider/Layers/CodexSessionRuntime.ts — openCodexThread() resumes with excludeTurns: true, then falls back to thread/start only when isRecoverableThreadResumeError() matches.
   • Recoverable snippets are missing-thread wordings (not found, missing thread, no such thread, unknown thread, does not exist, no rollout found). The matcher also requires the message to contain "thread".
   • The reported message is exactly list_turns is not supported yet. It does not contain "thread", so a snippet-only add of list_turns / not supported yet would still not match.
   • apps/server/src/provider/Layers/CodexAdapter.ts — startSession maps the failure to ProviderAdapterProcessError.
   • Android does not run Codex. The host is the Windows T3 server (codex-cli 0.154.0) spawning codex app-server. Desktop likely kept a live session; the mobile send (or a later startSession) is what hits resume.

   Not duplicates

   • [Bug]: GPT-5.5 Codex provider turn start fails with invalid thread/start payload priority #2584 — same stack, different cause (Invalid thread/start payload: priority vs fast|flex). Closed via Refresh Codex protocol bindings and adapter mappings #2590.
   • [Bug]: ProviderAdapterProcessError: Provider adapter process error (codex) for thread ...: session ... is archived. Run codex unarchive ... to unarchive it first. #10481 — ChatGPT-archived Codex session; needs thread/unarchive, not a fresh start.
   • Codex thread resume can exhaust server heap on large histories #7075 — heap exhaustion from loading full thread/resume history. T3 already sends excludeTurns: true.
   • openai/codex#37754 — same list_turns resume failure. Related upstream, not a T3 duplicate (no existing t3code issue mentions list_turns).

   Related T3 work: #6671 added no rollout found to the recoverable list and documented the "thread" gate. That fallback is silent (server warning only); there is no user-visible “session restarted” notice today.

   Suggested fix

   Treat -32601 / list_turns / not supported yet on thread/resume as a capability mismatch, not as a missing thread:

   1. Match on RPC code and/or list_turns, without requiring the word "thread".
   2. Fall back to thread/start so the T3 thread is usable again.
   3. Tell the user the Codex provider session restarted and native Codex context may be gone. The rollout is often still on disk — this is not the same as no rollout found.
   4. Log Codex CLI version vs the initialize handshake server version (helps catch leftover daemon / store skew).

   Do not fold this into the archived-session path (#10481) or the large-history path (#7075).

   Workaround

   Start a new thread. On the host: upgrade Codex, run codex doctor, and restart any leftover codex app-server daemon if CLI and daemon versions differ.

   Severity

   High for the affected thread (every turn fails). Accepting as a Codex resume-path bug with an upstream root cause T3 can mitigate.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   acceptedfeature request acceptedfeature request accepted

   upstream

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 18, 2026
3. pmf111 commented on Sep 18, 2026

   

   pmf111

   on Sep 18, 2026

   Author

   More actions

   Update from local diagnosis (reporter machine, T3 Code Alpha 0.0.42 desktop on Windows, Codex provider): updating the npm Codex CLI 0.154.0 -> 0.155.0 made every Codex provider status check time out on desktop ('Timed out while checking Codex app-server provider status'; trace shows probeCodexAppServerProvider/withCodexAppServerClient interrupted after ~10-20s, no codex processes survive). Rolling back to 0.154.0 restored successful checks. So 0.155.0 appears incompatible with (or hangs under) this T3 version's status probe. The original list_turns resume failure was unaffected by the update. Happy to open this as a separate issue if preferred.
4. pmf111 commented on Sep 19, 2026

   

   pmf111

   on Sep 19, 2026

   Author

   More actions

   Follow-up from the reporter machine: the failure evolved but stays on the same code path. After a corrupt 768MB thread_history_1.sqlite was moved aside and rebuilt, resume now fails with 'failed to list thread history: thread-store internal error ... (code: 11) database disk image is malformed', and the freshly rebuilt database is already malformed again within ~24h (verified: even PRAGMA integrity_check cannot open it). Same-device idle threads are affected too, not just cross-device resume. The PR branch has been extended accordingly: unreadable-history errors ('failed to list thread history', 'thread-store internal error', 'database disk image is malformed') now also fall back to thread/start. The recurring store corruption itself looks like an upstream Codex issue.
5. t3dotgg commented on Oct 2, 2026

   

   t3dotgg

   on Oct 2, 2026

   Member

   More actions

   Note

   🤖 GPT-6.1-Sol responding on behalf of Theo

   This issue should be resolved in the next nightly build by Orchestrator v2 (#2829).

   Please try that nightly. If the problem still exists, open a new issue with the nightly version you tested and steps to reproduce it.
6. t3dotgg

   closed this as completedon Oct 2, 2026