Codex mobile: one long thread opens blank despite notifications; latest-history read is stale

What version of the Codex App are you using (From “About Codex” dialog)?

Desktop host: ChatGPT/Codex app 26.903.71938, build 8576, bundle identifier com.openai.codex (read from the installed app's Info.plist).

Desktop-bundled runtime: codex-cli 0.153.4.

The exact mobile app version, phone model, and mobile OS version have not been collected. This is a report about the Codex mobile task/conversation surface connected to a local Mac host.

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

uname -mprs: Darwin 25.5.0 arm64 arm
sw_vers: macOS 26.5.1 (25F80)

What issue are you seeing?

One existing, long-running conversation is inaccessible on mobile: notifications for the task still arrive, but opening that task shows no conversation body.

The user confirmed that:

• Fully restarting the mobile app did not resolve it.
• Only this particular conversation is affected; other tasks open normally.

Recent assistant replies have not disappeared from the local rollout: a read-only inspection found the complete recent final answer in the persisted JSONL. However, the app's exposed read_thread tool, when asked for the latest two turns of this conversation, returned older turns from September 11 even though newer September 12 replies were present in the rollout and the thread metadata had a September 12 update time. One of the returned old turns was still labeled inProgress.

This suggests a per-thread history retrieval/state reconstruction or mobile loading problem. It does not establish which layer is responsible. In particular, the exposed read_thread result is a tool-level observation, not a direct capture of the phone's network response.

What steps can reproduce the bug?

Observed workflow (not yet a minimal synthetic reproducer):

1. Continue using the same local-hosted Codex conversation over several days, including long-running Goal activity, many tool results, and coordination with other tasks.
2. Reopen that conversation from the Codex mobile task surface after receiving task notifications.
3. Observe that notifications remain available but the conversation body is blank.
4. Fully restart the mobile app and reopen the affected conversation; the problem persists.
5. Open other task conversations from the same phone; they display normally.
6. On the Mac, read the original rollout without modifying it and compare recent final answers with the app's latest-turn retrieval. In this case the recent answer is persisted, but the retrieval exposes older turns.

The workload had already been stopped at the user's request when the display problem was investigated. The task remained capable of receiving follow-up questions and generating answers. A stopped/blocked Goal therefore does not by itself explain the missing conversation body.

What is the expected behavior?

The same task should display its saved messages on mobile, including its most recent completed answer. Large history should not leave the conversation entirely blank.

If history cannot be loaded, the app should show an actionable error/retry state. Latest-turn retrieval should be consistent with persisted recent messages, or explicitly report that its view is incomplete/stale.

Additional information

Read-only diagnostic observations on September 12, 2026:

• At the first rollout inspection, the file was 155,974,102 bytes (about 156 MB) with 31,461 JSONL records. Every record parsed as JSON. This is only syntax validation, not proof that the history is semantically intact.
• The record includes substantial tool output and compaction material; the byte count is not the size of plain user/assistant messages or necessarily the mobile network payload.
• A recent final assistant answer was present with timestamp 2026-09-12T13:18:40.479Z.
• An earlier same-day desktop log entry refers to the affected conversation:

  2026-09-12T07:15:19.040Z error [electron-message-handler]
  Turn not found for event
  conversationId=<redacted> turnId=<redacted>
  

  This is a diagnostic lead, not a proven cause of the mobile symptom.
• During the later history inspection, desktop log entries for thread/read, thread/turns/list, and thread/items/list recorded errorCode=null. That does not prove the returned history was current or that the phone rendered it.
• No phone console trace, network capture, or controlled test of a specific history-size threshold is available.

A fresh conversation with a short handoff summary was created while preserving the original conversation and project files. Its first completed answer was successfully retrieved through the app tool. The user has not yet confirmed mobile rendering of that replacement, so this is not claimed as a verified fix.

Potentially related: #38653 (large paginated history bootstrap) and #28340 (mobile task message loading). I have not established a shared root cause; the additional distinguishing evidence here is stale latest-turn retrieval despite newer messages in the local rollout.

Private conversation contents, project names, local usernames/paths, host addresses, and actual thread/turn IDs have been omitted. No complete rollout or diagnostic bundle is attached.

Start with related issues #38653 and #28340, then compare the exposed read_thread result with the persisted JSONL and the desktop logs for thread/read, thread/turns/list, and thread/items/list. A fix should make the affected task render its saved messages on mobile, or show an actionable error, while keeping latest-turn retrieval consistent with persisted recent messages.