[iOS Remote] Small paginated task fails when one serialized record is large, while larger tasks load

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

ChatGPT/Codex Desktop 26.831.20005 (build 7524), with bundled codex-cli 0.152.0.

What subscription do you have?

ChatGPT Pro 20x.

What platform is your computer?

Darwin 27.0.0 arm64 arm

The client displaying the failure is ChatGPT/Codex Remote on iOS. The exact iOS app version was not captured.

What issue are you seeing?

Some valid Codex tasks listed in iOS Remote fail to hydrate their message history and display:

Error loading messages

Other tasks on the same account, host, and mobile client load normally. Updating and restarting the Mac desktop app did not resolve the affected tasks.

The failing tasks remain readable through the Codex App Server API on the remote Linux host, so their persisted histories exist and are not obviously corrupt. Total rollout size is also not the determining factor: a roughly 4.56 MB task fails while a roughly 54.2 MB task loads successfully.

What steps can reproduce the bug?

1. Connect ChatGPT/Codex Remote on iOS through Codex Desktop on macOS to a remote Linux host running Codex App Server over SSH.
2. Select an existing paginated task whose history contains an individual serialized record of roughly 2 MB or larger.
3. Observe that the task shell may open, but its messages fail with Error loading messages.
4. On the same phone and host, open a larger control task whose individual records are smaller.
5. Observe that the larger control task loads successfully.

Four tasks were compared during the same reproduction window:

The individual task IDs and raw transcripts are intentionally omitted because they may expose private project content. A private in-app feedback report containing the reproduction details was submitted with feedback/session ID:

01a05e69-4884-7e71-b55e-88bfca7b644c

What is the expected behavior?

iOS Remote should load recent human-readable task history even when one command-output or compacted-history record is large. Oversized records should be byte-bounded, represented by a placeholder, truncated for the initial render, or loaded on demand rather than causing the entire message list to fail.

Additional information

This result suggests that total task size alone is not the trigger. Failure correlates more strongly with the size of an individual serialized message or command-output record, which may indicate a per-page or per-record decoding, transport, or rendering limit in the iOS Remote hydration path.

The updated Desktop logs also contained related state errors such as unknown conversation and conversation state not found from avatarOverlay, although no matching Codex App Server-side corruption or general server failure was found.

Related reports:

• #38653 describes a count-only paginated bootstrap without a byte limit.
• #38889 describes iOS message hydration failures for paginated tasks.
• #22705 describes the broader mobile metadata-load/message-hydration split.

This report adds the size-inverted control case: a small total rollout fails while a substantially larger rollout loads, with the outcome instead tracking the largest individual serialized record.

Start by reading related issues #38653, #38889, and #22705, then trace the iOS Remote message-hydration path and its Codex App Server API pagination. Compare per-record serialization, transport, decoding, and rendering limits using the reported size-inverted cases; done means a large individual record no longer prevents the task history from loading.