iOS mobile thread opens with metadata but message hydration fails: CodexClientError error 11

Open 💬 6 comments Opened May 14, 2026 by MaverickKB

What version of Codex CLI is running?

Two Codex versions are present on the Mac after the desktop update:

  • Desktop app bundled CLI: codex-cli 0.131.0-alpha.9
  • PATH/Homebrew CLI: codex-cli 0.130.0

What subscription do you have?

Unknown / not inspected from local context.

Which model were you using?

Observed from the ChatGPT iOS Codex mobile control surface on a thread showing 5.5 High in the composer. The issue appears to happen while opening/hydrating existing threads, before sending a new prompt.

What platform is your computer?

macOS 26.4.1, build 25E253

Codex Desktop app:

  • CFBundleShortVersionString: 26.513.20950
  • CFBundleVersion: 2816
  • Main desktop app-server process observed alive: /Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled

What issue are you seeing?

The ChatGPT iOS Codex mobile control UI can open a local desktop thread far enough to display thread metadata, but fails to hydrate the message list.

The mobile screen displays the thread shell successfully:

  • thread title
  • account / local Mac host row
  • composer
  • access mode (Full Access)
  • model/reasoning indicator (5.5 High)
  • diff summary pill (1 file changed, +112, -33)

But the message area shows this error instead of the conversation messages:

Error loading messages: The operation couldn’t be completed.
(CodexAppServer.CodexClientError error 11.)

Related user-visible behavior observed in the same mobile rollout window:

  • Some threads do not load at all from mobile.
  • Some completed desktop responses do not appear/update promptly on mobile after the response posts.
  • The desktop thread remains usable; this looks like mobile/relay/app-server hydration state rather than a local desktop crash.

Reproduction

  1. Update Codex Desktop to 26.513.20950 on macOS.
  2. Pair/use ChatGPT iOS Codex mobile control with the Mac.
  3. Open an existing active local thread from the mobile app.
  4. Observe that thread metadata and controls render.
  5. Observe that the message list fails with CodexAppServer.CodexClientError error 11.

This was observed around 2026-05-14 17:43 America/New_York.

Expected behavior

If mobile can list/open the thread and render its shell, it should also hydrate the message list or show a narrower recoverable state such as retry/reconnect/partial-history-unavailable.

Completed desktop turns should also update into the mobile thread reliably after they post.

Actual behavior

The thread shell renders, but messages fail to load with CodexAppServer.CodexClientError error 11. The user cannot read or continue that thread from mobile even though metadata and diff state are visible.

Local desktop log evidence near the failure window

No clean desktop app-server crash was observed. The desktop app-server was alive, and desktop logs showed normal routing for some thread methods, plus repeated turn-state/hydration-looking errors.

Representative log patterns from ~/Library/Logs/com.openai.codex/2026/05/14/codex-desktop-...-t0-i1-204642-0.log:

2026-05-14T21:40:33.889Z info [AppServerConnection] response_routed ... method=thread/list ... errorCode=null
2026-05-14T21:41:41.903Z info [AppServerConnection] response_routed ... method=thread/read ... errorCode=null
2026-05-14T21:41:42.022Z info [AppServerConnection] response_routed ... method=thread/goal/get ... errorCode=-32600
2026-05-14T21:41:42.022Z error [electron-message-handler] Request failed ... method=thread/goal/get ... error={"code":-32600,"message":"goals feature is disabled"}
2026-05-14T21:41:42.022Z warning [electron-message-handler] Failed to hydrate thread goal after resume ... error={"code":-32600,"message":"goals feature is disabled"}
2026-05-14T21:41:42.023Z info [AppServerConnection] response_routed ... method=thread/resume ... errorCode=null

Repeated nearby errors:

2026-05-14T20:51:01.457Z error [electron-message-handler] Item not found in turn state itemId=call_...
2026-05-14T21:15:29.991Z error [electron-message-handler] Item not found in turn state itemId=call_...
2026-05-14T21:19:37.386Z error [electron-message-handler] Item not found in turn state itemId=call_...
2026-05-14T21:40:55.119Z error [electron-message-handler] Item not found in turn state itemId=call_...
2026-05-14T21:45:31.001Z error [electron-message-handler] Item not found in turn state itemId=call_...

Additional context

OpenAI status was showing an active Codex incident around the same time (Codex Cloud and Code Review experiencing high failure rate). That may be separate from mobile local thread hydration, but it is useful launch-day context.

Related but not identical existing issue: #22693 covers a stale Codex run failed banner after bridge restart. This report is focused on message hydration failure where the mobile app loads thread metadata but cannot load messages.

View original on GitHub ↗

6 Comments

zorkary · 3 months ago

I’m seeing a similar mobile-only symptom: affected threads open to the loading skeleton UI, but the skeletons shimmer indefinitely and messages never hydrate. Smaller threads load normally.

The same large threads do load on macOS Desktop. I posted sanitized local size/structure metadata here: https://github.com/openai/codex/issues/21211#issuecomment-4462594654

Short version of that metadata:

  • 4 active rollout JSONL files are >100 MB, totaling ~3.0 GB.
  • Largest affected thread is ~2.1 GB with ~280k JSONL records.
  • Largest file parses cleanly, but contains one ~85 MB function_call_output record and multiple ~40-49 MB compacted.replacement_history records.
  • Other affected threads are ~416 MB and ~374 MB, also with repeated multi-MB compacted.replacement_history records.

So this looks like mobile message hydration/rendering getting stuck on very large but valid histories, not a corrupt local thread and not a general account loading issue.

aaronovz1 · 3 months ago

I'm hitting the same problem. None of my threads load message history.

<img width="1179" height="2217" alt="Image" src="https://github.com/user-attachments/assets/bea9eb3a-452a-4474-90a4-f2ae6863a90a" />

brucehuu · 3 months ago

The same problem:
CodexAppServer.CodexClientError error 11.
Is this problem fix now ?

Gelurban · 3 months ago

I'm still having the same error. It's not fixed yet and it's really annoying

Knies-IT · 3 months ago

Update:

I tested the same affected thread on iPad as well. It fails there with the same error, while the same chat loads fine on two different Macs.

Additional observations:

  • The affected threads are generally old and large.
  • sqlite3 ~/.codex/state_5.sqlite 'pragma integrity_check;' returns ok.
  • Reinstalling Codex helped in one case and allowed a previously failing thread to load again.
  • Sending a new message locally via Desktop/VNC appeared to “wake up” one affected thread and made it accessible remotely again, but this did not work for all affected threads.
  • The same failing thread can be opened normally on multiple Mac clients.

Based on this, the issue seems specific to the iOS/iPadOS mobile client rather than thread corruption or a local database problem.

viowai · 7 days ago

Still reproducible in the same failure class on 2026-08-21, with a size/context threshold now isolated.

  • Host: macOS; bundled Codex CLI 0.148.0-alpha.15
  • Surface: phone via Codex Remote (exact mobile OS/app version not captured)
  • Model: gpt-5.6-sol
  • Global config: model_context_window = 500000
  • Runtime task window reported by Codex: 475000
  • Affected thread peak last_token_usage.input_tokens: 305690
  • Desktop can open the same thread; mobile fails/hangs while loading the thread/messages
  • Smaller threads remain usable
  • Workaround: lower global model_context_window to 400000 (expected runtime effective window about 380000)

This suggests a large but valid context/history is a reproducible trigger for mobile hydration failure, rather than local thread corruption. No raw rollout, project content, local paths, or logs are attached.

A private /feedback report was also recorded with no logs attached. Feedback thread ID: 01a022a0-02e7-7293-902b-65197053528b.