iOS remote client times out loading long desktop Codex sessions and has no retry path #28480

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   iOSIssues related to the Codex iOS appIssues related to the Codex iOS app

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   remote

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Jun 16, 2026
2. github-actions commented on Jun 16, 2026

   

   github-actionsbot

   on Jun 16, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • Remote access performs poorly on weak networks, such as packet loss, high latency, or low bandwidth #28346
   • Codex mobile intermittently fails to open running task conversations #28340

   Powered by Codex Action
3. iamluheng commented on Aug 14, 2026

   

   iamluheng

   on Aug 14, 2026 – with ChatGPT Codex Connector

   More actions

   Sanitized reproduction with app-server evidence

   I reproduced this on an Apple Silicon macOS host with two active long-running threads. This comment intentionally omits task IDs/titles, workspace paths, repository names, source code, commands, commit hashes, network addresses, account identifiers, and conversation content.

   Environment

   • Host: macOS 26.5.1, arm64
   • Codex Desktop: 26.727.51351
   • Bundled Codex/app-server recorded by the affected threads: 0.146.0-alpha.9.2
   • iOS Remote client recorded by app-server: 1.2026.209
   • Observed: 2026-08-14

   Sanitized thread sizes

   • Selected thread A: about 107.6 MB / 40.3k persisted items
   • Selected thread B: about 718.7 MB / 312.3k persisted items
   • Two other already-loaded desktop threads: about 417.8 MB / 121.2k items and 291.9 MB / 135.0k items

   Both selected threads were alive and producing new events.

   What happens on each iOS Remote connection

   The app-server logs show that a single mobile connection does not fetch only the selected thread's recent visible messages. Instead it repeatedly:

   1. resumes another already-loaded desktop thread from its complete rollout;
   2. runs thread/turns/list for selected thread A from the beginning;
   3. runs thread/turns/list for another unrelated loaded thread from the beginning;
   4. runs thread/turns/list for selected thread B twice concurrently.

   One connection therefore parses approximately 2.10 GiB of rollout history. The 718.7 MB thread takes about 3.0-3.1 seconds per full scan, and the duplicate requests overlap.

   Across six consecutive connections, the same pattern repeated. The client disconnected roughly four seconds after the history requests began; the host then logged:

   dropping message for disconnected connection
   

   The client reconnected and restarted the same full-history work, producing a retry/load storm.

   Integrity and resource checks

   • Every rollout replay reported parse errors: 0.
   • The state database integrity check returned ok.
   • No database lock or missing rollout was observed.
   • The host had ample free memory and disk with no swap pressure.
   • During repeated replay, app-server CPU briefly exceeded three cores and RSS grew above 3 GiB.

   This appears to be an eager hydration/fan-out problem rather than corrupt state or insufficient host resources.

   Expected protocol/UI behavior

   On remote connection or thread selection, return only:

   • thread metadata and active-turn status;
   • a bounded recent tail, preferably the newest 50-100 visible user/assistant text messages, subject to a small byte cap;
   • a cursor for older visible messages;
   • live events after the snapshot cursor.

   The initial response should exclude old tool outputs, hidden reasoning/event records, images/blobs, and unrelated loaded threads. Older text should load lazily when scrolling. Heavy tool output should require a separate explicit fetch.

   Additionally:

   • deduplicate concurrent thread/turns/list calls for the same thread;
   • do not hydrate every desktop-loaded thread when mobile connects;
   • do not block selected-thread rendering or the composer behind unrelated history;
   • enforce server-side item/byte caps so a client omission cannot trigger an unbounded response;
   • allow a timed-out client to resume from its last cursor instead of restarting from byte zero.

   This is consistent with the requested direction in #21211 and #25779, and complements the Android evidence in #38023. The iOS-specific additional finding here is the cross-thread fan-out plus duplicate full read of the largest thread on every connection.
4. dbjaredh commented on Sep 4, 2026

   

   dbjaredh

   on Sep 4, 2026 – with ChatGPT Codex Connector

   More actions

   Additional reproduction (2026-09-04): I am seeing a persistent thread-specific variant of this problem with Codex Desktop + ChatGPT iOS Remote.

   Environment/behavior:

   • Codex Desktop thread continues to work and update normally.
   • ChatGPT iOS Remote can connect to the same desktop host.
   • Other Codex threads on that same host continue to update correctly on iOS.
   • One specific existing/long-running thread becomes stale/frozen on iOS and stops reflecting new desktop activity.
   • The desktop copy of that same thread remains fully functional and current.

   Troubleshooting already attempted without resolving the affected thread:

   • force-close/reopen ChatGPT iOS
   • restart Codex Desktop
   • sign out/in
   • disconnect/re-pair Remote Control
   • reconnect/reopen the affected thread

   The important discriminator is that the failure follows one specific thread rather than the account, phone, network, or desktop host. Other threads continue working through Remote.

   This looks consistent with a thread resume/hydration/state synchronization problem rather than general transport connectivity. It may also be related to #38787 if long thread history causes thread/resume reconstruction to stall, although in this reproduction the visible symptom is a persistently stale mobile representation while the already-loaded desktop thread remains healthy.

   Expected behavior: iOS Remote should hydrate the current desktop thread state and continue receiving subsequent events/turns, or explicitly detect stale state and recover/retry.

   Actual behavior: iOS remains on an older/stale state for this thread despite the desktop thread continuing normally and despite re-pair/restart attempts.
5. goodserg commented on Sep 5, 2026

   

   goodserg

   on Sep 5, 2026

   More actions

   Additional reproduction on Windows + ChatGPT iOS Remote, observed on 2026-09-05. The failure is persistent for one long-lived thread; other threads on the same host, including a newly opened diagnostic conversation, load on the same phone. Not every other thread was tested.

   Environment

   • Host: Windows, OS build 10.0.26200.0, x64.
   • Installed desktop package: OpenAI.Codex_26.901.5003.0_x64.
   • Running bundled Codex/app-server executable reports codex-cli 0.153.3.
   • Mobile client identified in app-server requests: codex_chatgpt_ios_remote, version 1.2026.237.
   • iPhone using a 5G connection; exact iOS version not collected.

   Reproduction and visible result

   1. Connect ChatGPT iOS Remote to the Windows desktop host.
   2. Open the affected existing thread. The thread title, host row and composer render, but messages do not.
   3. The Russian UI shows Ошибка загрузки сообщений. (Error loading messages) and a Retry button.
   4. Retry/reopen the same thread. The error persists. A later screenshot also shows Не удалось восстановить подключение к задаче (Could not restore the connection to the task).
   5. Open another thread on the same host: it loads successfully.

   Screenshots show the failure at approximately 14:52 and again at 15:14 UTC+03:00. Unlike the original report, a Retry action is now present, but it does not recover this thread.

   Read-only diagnostics

   • Persisted rollout: 3,455,813,805 bytes, 360,769 JSONL records. These are internal records, not 360k visible chat messages.
   • 662 compacted records account for 2,367,130,244 bytes.
   • Largest record: 10,383,007 bytes.
   • 33,168 inline data:image/ occurrences, potentially including repeated copies in checkpoints; this is not a count of distinct images.
   • A full streaming JSON syntax check found two invalid records (Invalid control character); the other 360,767 records parsed. The original rollout has not been modified. This is a potential additional factor, so I am not claiming a confirmed identical root cause to the valid-rollout reports above.
   • A separate read of this thread through the desktop thread-management tool also timed out.

   Sanitized host log sequence during the first reported mobile attempt:

   2026-09-05T11:52:13Z composing running thread resume response
     thread_id=<affected-thread> connection_id=4
     active_turn_present=false active_turn_id=None active_turn_status=None
   2026-09-05T11:53:31Z dropping message for disconnected connection: ConnectionId(4)
   2026-09-05T11:53:34Z timed out waiting for connection RPCs to drain
     connection_id=ConnectionId(4) timeout_seconds=30
   

   These events establish a failed resume/disconnect sequence, but do not by themselves establish whether response reconstruction, transport size, the two malformed records, or a combination caused the failure. In particular, no Max payload size exceeded error has been established for this reproduction. The affected thread had no active turn at the captured resume, which differs from the active-turn example in #38787.

   Could maintainers advise on a supported, non-destructive recovery path for an existing oversized thread and whether the two malformed records should be investigated separately? Bounded loading of recent messages and a recoverable partial-history state would preserve access to the task. Related investigations: #38787 and #36423.

   Thread IDs, titles, host/account identifiers, private paths, raw rollout/log files, screenshots with private labels, and conversation content are intentionally omitted.
6. Jackten commented on Sep 24, 2026

   

   Jackten

   on Sep 24, 2026

   More actions

   A possible host-side cause for this symptom is in #47842. A single config/read that hangs on the file system holds the app-server's global "config" request queue, and nothing cancels it. Mobile Remote then stays connected but can't load threads until the app-server restarts. If you hit this, check the host log for "timed out waiting for connection RPCs to drain" around the time of the failure.
7. Marc2629 commented on Oct 8, 2026

   

   Marc2629

   on Oct 8, 2026 – with ChatGPT Codex Connector

   More actions

   Confirming that I'm still seeing this on Windows 11 (Codex Desktop) → ChatGPT iOS Remote as of 8 October 2026.

   I regularly get “Message could not be loaded due to timeout” when opening long-running Codex tasks on my iPhone. It seems particularly associated with threads that have accumulated a lot of activity/history, making it difficult to check the latest progress remotely.

   Loading only the latest messages first, with an option to fetch older history, and providing reliable retries after a timeout would make a big difference.
8. we-yu commented on Oct 9, 2026

   

   we-yu

   on Oct 9, 2026 – with ChatGPT Codex Connector

   More actions

   I can reproduce a possibly related issue with a much smaller case on iOS.

   Environment

   • ChatGPT/Codex iOS app
   • Codex Cloud task (not a Mac/Desktop Remote task)
   • 4G connection

   Reproduction

   1. Create a fresh Codex Cloud thread.
   2. Attach 5 normal-sized reference images.
   3. Send a single prompt asking imagegen to generate 3 image variations.
   4. Wait until all 3 images are generated and the task is fully complete.
   5. Force-close the iOS app.
   6. Reopen the app and open the same thread.

   Observed
   The thread can time out while loading its messages and become temporarily inaccessible.

   A few additional observations from another affected thread:

   • A sufficiently fast Wi-Fi connection can sometimes load the affected thread successfully.
   • After it has loaded successfully over Wi-Fi and I exchange some text-only messages, it may later work over 4G as well.
   • Long text-only threads appear less likely to trigger the problem than threads with recent image-generation activity.

   These are observations only; I am not claiming a root cause. The smaller reproduction suggests that a very long thread or Desktop Remote is not required to trigger the problem.