Repository navigation
iOS mobile thread opens with metadata but message hydration fails: CodexClientError error 11 #22705
Description
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.20950CFBundleVersion: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
- Update Codex Desktop to
26.513.20950on macOS. - Pair/use ChatGPT iOS Codex mobile control with the Mac.
- Open an existing active local thread from the mobile app.
- Observe that thread metadata and controls render.
- 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.
Activity
zorkary commentedon May 15, 2026
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: #21211 (comment)
Short version of that metadata:
function_call_outputrecord and multiple ~40-49 MBcompacted.replacement_historyrecords.compacted.replacement_historyrecords.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 commentedon May 17, 2026
I'm hitting the same problem. None of my threads load message history.
brucehuu commentedon May 24, 2026
The same problem:
CodexAppServer.CodexClientError error 11.
Is this problem fix now ?
Gelurban commentedon May 28, 2026
I'm still having the same error. It's not fixed yet and it's really annoying
Knies-IT commentedon May 29, 2026
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:
Based on this, the issue seems specific to the iOS/iPadOS mobile client rather than thread corruption or a local database problem.
viowai commentedon Aug 21, 2026
Still reproducible in the same failure class on 2026-08-21, with a size/context threshold now isolated.
0.148.0-alpha.15gpt-5.6-solmodel_context_window = 500000475000last_token_usage.input_tokens:305690model_context_windowto400000(expected runtime effective window about380000)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
/feedbackreport was also recorded with no logs attached. Feedback thread ID:01a022a0-02e7-7293-902b-65197053528b.diegocantarero commentedon Sep 10, 2026
Additional report — 2026-09-10 (UTC-06). Similar symptom, not a confirmed identical root cause.
User reports iOS Remote lists desktop tasks, but opening ANY tested existing task fails to load conversation messages. Screens show Spanish “Error al cargar los mensajes.” and subsequently a host-level request timeout (“La solicitud a Codex excedió el tiempo de espera.”). No numeric error 11 was shown in this occurrence.
User reports both mobile and desktop apps updated. Verified macOS desktop CFBundleShortVersionString: 26.903.71938. Exact iOS build not yet collected. Read-only desktop diagnostic successfully retrieved one affected task including a substantive persisted final answer; that does not prove the mobile transport or full history request works. One main ChatGPT process was observed, configured AC sleep=0, swap used=0 MB. No credential deletion, database edits, competing app-server startup or process termination performed.
Scope matters: listing metadata succeeds while conversation retrieval fails across all tasks tested by the user; this is not currently demonstrated to be only a long-thread issue. Wi-Fi versus cellular comparison and a fresh short-task acceptance test remain unverified.
Please advise supported diagnostics to correlate mobile history-load requests with desktop/relay request failures (method, latency, sanitized status), and a non-destructive recovery that preserves running tasks. Is a full-history timeout, shared queue/backpressure, or mobile decoding/compatibility failure distinguishable through supported diagnostics? These are hypotheses, not asserted causes. Please keep this distinct from Computer Use -10005/window-control errors.
No private conversation content, task IDs, account identifiers, credentials, or raw logs included.
diegocantarero commentedon Sep 11, 2026
Follow-up with stronger bounded evidence (2026-09-11 00:32 UTC): a desktop task-read tool returned a completed latest turn with items=[] for an affected conversation. The exact local rollout has an assistant final response and task_complete for that SAME turn, final length 931 characters. Thus empty retrieval is not evidence of absent generation. This does not yet prove the mobile and task-tool retrieval paths share a root cause.
The local rollout is approximately 51.3 MB; actual mobile response/payload size is unknown. User screenshots show host/task list, then spinner, then Error loading messages. All attempted conversations reportedly fail, not just this one.
Separately, a current desktop log recorded three thread/read -32603 responses at 2026-09-10T23:58:15Z for ONE OTHER context, error: failed to read thread: thread-store internal error: failed to read session metadata [redacted]; rollout at [redacted] is empty. That context is NOT the affected conversation above; no causal attribution to the iOS attempt.
Please investigate projection/message retrieval consistency and provide a supported non-destructive repair or read path. No raw transcripts, IDs, credentials, or private paths attached. No DB modifications or regenerating completed work.