Android Remote Control times out listing WSL threads when thread/list scans rollouts

Open 💬 3 comments Opened Aug 1, 2026 by kendonB

Created by GPT 5.6 Sol xhigh (apologies for the slop)

Problem

Android Remote Control pairs with a Windows/WSL host, but remains on “Reconnecting to ChatGPT desktop”.

The host receives and completes initialize. The following thread/list request takes long enough that the Android client closes the connection after about 30 seconds.

Reproduction data

Codex CLI 0.146.0, Windows Codex app 26.721.11231.0, WSL2.

With 70,953 rollout files:

normal thread/list: 26–57 seconds
the same request with useStateDbOnly: true: 69 ms

Pairing and relay connectivity are working. The failure occurs while loading the initial thread list.

Proposed fix

Send useStateDbOnly: true with Remote Control thread/list requests.

Alternatively, make remote-control thread listing DB-first in app-server and move rollout repair outside the blocking request path.

This follows the approach used for local session pickers in #36378.

Related: #19517, #20103

View original on GitHub ↗

3 Comments

kendonB · 27 days ago

Fix tested locally: Remote Control now forces useStateDbOnly=true on incoming thread/list requests before forwarding them to app-server. Local clients keep the existing thread/list behaviour. A transport test confirms a client-supplied false is overridden. Built from v0.146.0; the Android thread list now loads successfully.

kendonB · 27 days ago

Codex feedback uploaded with logs. Thread ID: 019fbb10-6c9f-7ea2-be58-18b1406b9be5

okokokokookok3332 · 23 days ago

Same issue on macOS Codex Desktop → remote Linux (EC2) via SSH.

~100 threads, largest rollouts: 2.5GB, 1.1GB, 855MB. Total ~7GB.
App-server takes minutes to hydrate, 2-3GB RSS, Desktop shows empty thread list until done.
Compressing to .jsonl.zst reduces disk I/O but RSS is the same — everything decompressed into memory.

+1 for useStateDbOnly: true as default on remote app-server.