Android Remote: 50 MiB fs/readFile download times out after 30000ms while local RPC completes in 0.258s

Android Remote: large fs/readFile response times out after 30 seconds

Environment

• Host: macOS, ChatGPT/Codex desktop 26.908.70816 (bundle 9275).
• Client: ChatGPT Android 1.2026.251, using Remote (version reported by the user).
• Device: Samsung Z Fold8, as reported by the user.

Reproduction

1. Create a ZIP containing 5 MiB of random data on the connected host.

2. Return a Markdown link to the absolute workspace path in the Remote chat.

3. Open the link on the phone: the user reports success in 3–5 seconds.

4. Repeat with a ZIP containing 50 MiB of random data.

5. The phone displays “Couldn’t open file” with:

   Timed out waiting for app-server response to fs/readFile for seq_id 546 after 30000ms.

A 209-byte ZIP also succeeds. A 232,958,612-byte APK fails to download through
Remote, while a GitHub-hosted copy can be downloaded and verified from the host.
The GitHub route has not yet been confirmed on the phone.

Host-side control

A separate instance of the installed app-server binary was initialized over
stdio with experimentalApi enabled. Read-only fs/readFile requests used the
same generated ZIPs. No agent turn was started and no app configuration changed.

• 5,243,170-byte ZIP: 6,990,896 base64 characters; full local RPC completed in 0.029 seconds.
• 52,429,100-byte ZIP: 69,905,468 base64 characters; full local RPC completed in 0.258 seconds.

Established facts and remaining uncertainty

The screenshot establishes a 30-second request deadline. Small remote transfers
work, and the local server can return the larger file quickly. This narrows the
failure to the Remote path/client rather than basic host file readability or
APK handling alone.

The evidence does not yet distinguish slow remote transport, large-response
rejection/drop, or mobile response processing. It does not establish a fixed
file-size limit or prove that increasing the timeout alone would fix it.

Expected behavior

Large supported files should transfer reliably with progress, cancellation and
an appropriate transfer deadline, ideally using chunked/streamed downloads.
If there is a size limit, report it explicitly instead of a generic RPC timeout.

Related reports (not confirmed duplicates):

• https://github.com/openai/codex/issues/33358
• https://github.com/openai/codex/issues/36263

Start at the Remote fs/readFile request path and the app-server RPC handling described in the report, comparing the local stdio control with the Android transfer. Reproduce with the 5 MiB and 50 MiB ZIPs, then trace whether transport, response handling, or the 30-second deadline fails. Done means large supported files transfer reliably with progress, cancellation, and an appropriate error or deadline.