Android Remote fails during thread/list when unbounded previews make the first response ~259 KB

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

• Microsoft Store package: OpenAI.Codex 26.818.2441.0
• Desktop client version observed in logs: 26.818.21641
• Bundled CLI/app-server: codex-cli 0.148.0-alpha.21
• ChatGPT Android: 1.2026.223

What subscription do you have?

Not captured in the local diagnostics. Pairing and the Remote relay both authenticated successfully.

What platform is your computer?

Host:

Microsoft Windows NT 10.0.26200.0 x64

Remote client:

• Android 14
• moto g power 5G - 2023

What issue are you seeing?

Android Remote paired successfully with the Windows host, but repeatedly cycled through Looking for ChatGPT desktop → Reconnecting → Failed to connect.

The desktop Remote WebSocket was connected and a fresh revoke/re-pair completed successfully. The failure began after the remote connection received initialize and then requested thread/list. The request never completed over Remote, even though the identical call completed locally in about 1.5–2.0 seconds.

A controlled before/after test isolated the active thread-list payload as the trigger:

The active profile contained 162 unarchived vscode threads. Twenty-seven had first user messages longer than 512 characters; many were handoff prompts between 8,437 and 13,796 characters.

The state DB already held bounded cached previews, but default thread/list ignored those values while scanning/reconciling rollout JSONL and returned the full first user message as Thread.preview. Migrating one rollout to paginated history did not change that default list behavior.

Using the supported thread/archive API to archive those 27 long-preview threads reduced the same default 100-item response from 258,954 to 90,054 bytes. After toggling Remote off/on, the already-paired Android device connected immediately and successfully sent a message to the desktop task.

This A/B result strongly indicates an unhandled Remote payload-size/envelope boundary combined with unbounded list previews. The exact transport threshold was not established.

Sanitized host sequence from a failing attempt:

remote connection: initialize
remote connection: thread/list
(no response delivered; request remains open)
subsequent retry: initialize -> client disconnect

There was one desktop app-server process, the relay connection was healthy, and both Codex state databases passed integrity checks. Restarting Windows, revoking/re-pairing the phone, and toggling Remote did not fix the problem while the large list payload remained.

What steps can reproduce the bug?

1. On a desktop Remote host, retain enough active threads that the first page includes many large first user messages. In this case, 27 threads began with 8–14 KB handoff prompts.
2. Confirm that default thread/list with limit: 100 and sourceKinds: ["vscode"] returns a response around 259 KB, with full first messages mapped into preview.
3. Enable Remote and pair ChatGPT Android.
4. Attempt to connect. Observe that initialize succeeds, thread/list is received by the host, and the phone then reconnects/fails.
5. Bound the previews or archive enough long-preview threads so the default response is around 90 KB.
6. Toggle Remote off/on and retry from the same paired phone.
7. Observe that Remote connects and can send messages.

A useful implementation-level regression test would send a thread/list result larger than the Remote envelope limit and verify that it is chunked/paged or rejected explicitly instead of silently leaving the client in a reconnect loop.

What is the expected behavior?

• Long initial prompts should not prevent Android Remote from connecting.
• thread/list should send a bounded display preview rather than the complete first user message.
• The Remote initial list could use the bounded state-DB representation, request useStateDbOnly: true, or chunk/page the response.
• If a transport limit is exceeded, the host/client should receive a clear error and the outstanding request should be cancelled rather than silently stalling.

Additional information

Related, but not exact duplicates:

• #39815 tracks the same-day Windows/Android symptom cluster; this result replaces the earlier service/handshake hypotheses for this particular host with a reproducible local data-volume trigger.
• #36416 is the same initial thread/list stage, but its failure is a 26–57 second rollout scan timeout. Here, the default call completed locally in about 2 seconds and payload size was the changing variable.
• #36423 reports a Remote envelope failure for oversized thread/read; this may be the same transport/error-handling family at a different endpoint.
• #21211 already documents that first_user_message can make thread/list previews unbounded.

No account, device, server, environment, installation, or pairing identifiers are included. Raw logs are not attached because nearby headers contain authentication material; sanitized excerpts can be provided.

Start at the Remote initialize/thread/list entry points and the thread/list preview path; compare default scanning with useStateDbOnly: true using the 100-item reproduction. Add a regression test with an oversized thread/list result and verify that previews are bounded or the request fails clearly and is cancelled instead of stalling.