Skip to content

Android Remote stays stuck loading a large conversation while short conversations work #47148

Open

Description

@PolymerWrites

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

Windows desktop app package: 26.915.4065.0 (observed on September 21, 2026). Android app version not yet collected.

What subscription do you have?

ChatGPT paid subscription; reported plan type: prolite.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 (host); ChatGPT for Android using Remote (client).

What issue are you seeing?

Opening a long-running, image-heavy conversation through Remote in ChatGPT for Android leaves the conversation stuck on the loading screen. I cannot view the latest messages or continue that conversation from the phone. Other, shorter conversations on the same host are accessible from the same phone.

Observed on September 21, 2026, around 21:00 UTC+8. The affected conversation can be read on the Windows desktop host. There is no error text available from the phone to include; the reported symptom is persistent loading.

What steps can reproduce the bug?

  1. Connect to a Windows desktop host using Remote in ChatGPT for Android.
  2. Open an existing long-running conversation containing many image-generation iterations and tool records.
  3. Observe that the conversation remains on the loading screen and cannot be continued from the phone.
  4. Open a shorter conversation on the same host from the same phone; it loads successfully.

This reproduces in my existing setup. I do not yet have a minimal synthetic reproduction or a measured size threshold. No private conversation transcript or images are attached.

What is the expected behavior?

The latest messages and composer should become usable without waiting for the entire conversation history and all media to be loaded or processed. Older messages and images should load on demand as I scroll back.

If loading fails, show a useful error and a retry option instead of leaving the conversation on a loading screen. Users should be able to continue an established conversation without splitting it into new chats solely to make Remote usable.

Additional information

Diagnostic observations:

  • The affected conversation is readable on the desktop host; its latest turn was reported as completed without a turn error.
  • Host logs recorded an Android Remote thread/resume request at 21:03 UTC+8, indicating that a request from the phone reached the host.
  • The local session transcript file measured 564,533,425 bytes (approximately 565 MB). This is the on-disk transcript size, NOT a measurement of data transferred to the phone or mobile memory usage.
  • Shorter conversations work through the same Remote connection, while this large conversation does not.

Please investigate long/image-heavy conversation history retrieval, transfer, pagination, lazy loading, and mobile rendering. The exact cause is not established: these observations do not prove that the app downloads the entire transcript or that file size alone causes the failure.

Activity

  1. github-actions commented on Sep 22, 2026

    @github-actions
    Contributor

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

    Powered by Codex Action

  2. PolymerWrites commented on Sep 22, 2026

    @PolymerWrites
    Author
  3. Fan1K413 commented on Oct 1, 2026

    @Fan1K413

    I also see this with Codex Cloud in the ChatGPT Android app, in addition to Remote:

    • Long conversations containing many images and other resources fail to load on mobile.
    • The same affected Codex Cloud conversations remain usable on desktop.
    • Starting a new conversation only helps temporarily. My task requires many images, so the loading failure returns after a few rounds of conversation.

    This adds a similar mobile Codex Cloud reproduction to the Remote behavior reported here; I have not confirmed whether they share the same root cause.

  4. PawelW2201 commented on Oct 16, 2026

    @PawelW2201

    I’m also experiencing recurring message-loading failures in Codex Remote on Android.

    I receive notifications containing the agent’s new messages, but the conversation itself does not load in the app. The error shown is “Timed out loading the messages for this task.” Other remote conversations work, and an affected conversation may work one day and fail again the next. Sending another message has not reliably unblocked it.

    This prevents me from reviewing completed work or communicating directly with the affected task from my phone. Please investigate this loading failure.

  5. herbalizer404 commented on Oct 16, 2026

    @herbalizer404

    Additional reproduction and measurements from a Linux CLI Remote Control host, with macOS desktop as a working comparison.

    Environment during reproduction:

    • Host CLI and managed app-server: 0.162.1, Linux x86_64.
    • ChatGPT Android: 1.2026.279 (versionCode 2627911), Pixel 11 Pro.
    • The same affected sessions open successfully from the macOS desktop client, confirmed by the user. Exact macOS client build was not collected.
    • Reproduced again after upgrading BOTH the CLI and managed app-server to 0.163.0. Both versions were verified with codex app-server daemon version; the user confirmed that both affected sessions still fail to open on Android.

    Observed behavior:

    1. Two image-heavy sessions fail on Android with the localized equivalent of "Timed out loading the messages for this task. Try again."
    2. A smaller session opens and accepts messages through the same host connection.
    3. Server logs confirm the Android client reaches the host, resumes the affected sessions and requests thread/turns/list followed by multiple thread/items/list calls.

    Original measurements on 0.162.1, using a separate read-only client on the host's local Unix socket:

    Read Response bytes Local round-trip
    Thread A, turn summaries 7,999 0.0035 s
    Thread B, turn summaries 13,919 0.0024 s
    Thread A, full turn history 15,286,171 0.1383 s
    Thread B, latest single turn with full items 85,449,378 1.3432 s
    Thread A, 50-item page in an image-containing turn 2,769,032 0.0206 s
    Thread B, latest 50-item page 25,625,655 0.2000 s

    Retested the same image-bearing item-page requests with CLI and app-server 0.163.0:

    Read on 0.163.0 Response bytes Local round-trip
    Thread A, same 50-item page 2,769,032 0.0201 s
    Thread B, same 50-item page 25,625,655 0.1884 s

    The page payload sizes and inline-image counts are unchanged by that upgrade.

    The 50-item pages above were independent diagnostic requests with explicit page sizes. The exact page sizes and parameters sent by Android were not captured, so these measurements are NOT proof of the byte counts downloaded by Android.

    The largest measured item page includes 12 imageGeneration items with inline base64 results. All 58 generated-image files across the two sessions exist on disk, and their bytes match the inline results. These observations do not suggest missing image assets or lost sessions.

    Assessment:

    • The host can return thread summaries promptly.
    • Image-bearing item pages can be large even with item pagination.
    • The desktop/mobile difference and the measured payloads support investigating history hydration, inline media transfer, mobile parsing/rendering, and the history-loading deadline.
    • The exact bottleneck has NOT been isolated. No altered-condition successful Android retest has established a root cause or a fix.

    Potential direction: make messages and the composer usable from the small turn summaries, defer image content until needed, and budget item pages by bytes as well as item count. PR #21110 proposed deferred image content earlier, but was closed without merging; it may be useful prior design context rather than an available workaround.

    No private conversation text, images, credentials, project names, filesystem paths, or real thread IDs are included in this report.

  6. MemorexTV commented on Oct 17, 2026

    @MemorexTV

    Additional Windows/Android reproduction, still present on October 17, 2026.

    Environment:

    • Host: Windows Server 2022 Datacenter.
    • Last recorded Codex Desktop package: 26.1007.2314.0; CLI: 0.162.0-alpha.17.2.
    • ChatGPT for Android: 1.2026.279 (11), collected from the About screen during this investigation; any subsequent mobile update has not been independently checked.

    Observed behavior:

    • Android shows: “Beim Laden der Nachrichten dieser Aufgabe wurde das Zeitlimit überschritten. Versuche es erneut.” (Timed out loading this task's messages.)
    • The affected conversation remains readable on the Windows host. Another conversation on the same host opens on the phone.
    • Restarting both the phone and desktop app did not resolve the problem. It occurs over both Wi-Fi and mobile data/roaming.
    • As a workaround, a fresh local conversation was created without copying or forking the old transcript. It initially opened on Android.
    • After displaying existing images and generating ten new images, this new conversation also became inaccessible on Android. Its local JSONL grew from approximately 135 KB to 70 MB.
    • On October 17 the image-generation turn is completed, the conversation is idle, and there is no pending approval, but the mobile loading error persists.

    Read-only diagnostic findings:

    • The latest turn is accessible through the local paginated app interface in approximately 1.9 seconds; underlying local read/list requests completed in 4–614 ms without errors.
    • The ten generated image files and accompanying text/manifest exist locally.
    • A streaming JSON syntax check on October 15 found no malformed records in the new transcript.
    • Host commit usage was approximately 23.9/64.4 GB on October 17, not commit exhaustion.
    • Desktop logs around turn completion contain repeated ResizeObserver loop completed with undelivered notifications errors. A causal link to the Android timeout is NOT established.

    The 70 MB figure is on-disk transcript size, NOT measured mobile transfer size or evidence of a fixed size limit. Image/tool-event hydration, transport, pagination, or rendering remain hypotheses, not confirmed root causes.

    Expected: newest messages and composer remain accessible on Android, with older media/history loaded incrementally.

    No private conversation contents, images, paths, thread/account identifiers, or raw logs are attached.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingperformanceremote

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions