Remote Control App Sessions Broken on Android App when using Ubuntu WSL2 on Windows

What version of Codex CLI is running?

0.153.4

What subscription do you have?

Pro 20x

Which model were you using?

Astra

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What terminal emulator and version are you using (if applicable)?

VS Code 1.134.0; host environment Ubuntu 24.04 on WSL2

Codex doctor report

What issue are you seeing?

1 +# Android Remote fails to load connected Codex hosts; thread/list takes 46.6 seconds
2 +
3 +## Impact
4 +
5 +I cannot open or steer my current Codex terminal sessions from ChatGPT Remote on
6 +my Android phone. Sessions are running in VS Code terminals on a Windows machine
7 +with Ubuntu under WSL2. The phone remains on "Looking for remote host..." and
8 +eventually displays "Failed to connect to ChatGPT desktop. Make sure the ChatGPT
9 +desktop app is open, then try again." Both paired host indicators turn red.
10 +Sometimes the desktop host shows older conversations, but the current terminal
11 +sessions still cannot be controlled.
12 +
13 +## Versions and environment
14 +
15 +- Codex standalone CLI and persistent app-server: 0.153.4.
16 +- Windows desktop app: OpenAI.Codex 26.901.5003.0; its bundled WSL server was
17 + previously verified as 0.153.3.
18 +- VS Code: 1.134.0; host environment Ubuntu 24.04 on WSL2.
19 +- Phone: Samsung Galaxy Z Fold6, SM-F956U1, Android 16.
20 +- ChatGPT Android was updated from 1.2026.237 to 1.2026.244 during diagnosis.
21 + The failure reproduced after the update on 2026-09-07 at 19:06:10 UTC.
22 +- Existing history: about 922 thread records; 904 active JSONL rollout files
23 + totaling approximately 39.8 GB. Current conversations use paginated history.
24 +- The terminal uses the persistent daemon's Unix WebSocket control socket.
25 + A separate desktop-owned WSL process shares the canonical SQLite database
26 + through an existing sqlite_home override, while keeping a separate CODEX_HOME.
27 + Both installations have existing phone pairings.
28 +
29 +## Reproduction
30 +
31 +1. Keep the Windows desktop app open and the persistent WSL Codex server running
32 + with remote control enabled.
33 +2. Start or continue a Codex session in a VS Code terminal connected with
34 + codex --remote unix://$HOME/.codex/app-server-control/app-server-control.sock.
35 +3. On the paired Android phone, open Remote and select the CLI session host.
36 +4. Wait for sessions to load. The loading screen ends in the error above.
37 +
38 +Expected: current sessions appear promptly and can be opened and steered.
39 +Actual: prolonged loading, then failure, despite successful host registration
40 +and requests arriving at the server.
41 +
42 +## Verified diagnostics
43 +
44 +- remoteControl/status/read reports connected on the persistent daemon.
45 +- remoteControl/client/list confirms the Android device and updated app version.
46 +- thread/loaded/list and an indexed thread/list show both current conversations.
47 +- codex doctor reports configuration, authentication, provider reachability,
48 + Responses WebSocket handshake, installation, and database integrity as healthy.
49 +- Android initialize and thread/list requests reach the server. Client name in
50 + server logs: codex_chatgpt_android_remote, client version reported as dev.
51 +- Before the phone update, one Android thread/list request began at
52 + 18:49:57 UTC and was still reading rollout metadata at 18:50:34 UTC.
53 +- After the update, fresh Android list requests reached both hosts and continued
54 + reading older rollout histories before the phone failed again.
55 +
58 +After a normal initialize handshake, compare these thread/list parameters:
59 +
60 +json 61 +{"limit":100,"sortKey":"updated_at"} 62 +
63 +
64 +This exceeded a 35-second local client timeout. A longer observation returned
65 +100 threads in 46.649 seconds, including today's conversations.
66 +
67 +json 68 +{"limit":100,"sortKey":"updated_at","useStateDbOnly":true} 69 +
72 +It included the same two current conversations as active. A normal limit=20
73 +request with the default sort took 5.611 seconds.
74 +
75 +The slow scan/repair listing path is a strong lead, but the exact Android list
76 +parameters and client timeout were not captured. Client-side decoding or other
77 +causes have not been conclusively excluded. Please investigate whether mobile
78 +host loading can use the existing index and perform repair separately, and why
79 +this failure is presented as an unavailable desktop host.

What steps can reproduce the bug?

Uploaded thread: 01a07d31-0d8f-7162-8f81-de52462536c5

What is the expected behavior?

Control on remote sessions via phone app.

Additional information

No response

Start by reproducing the Android remote host flow with the reported thread/list requests, comparing the default listing with useStateDbOnly=true. Inspect the remoteControl initialization and thread/list entry points, using the reported 35-second timeout and 46.649-second response as the performance baseline. Done means current sessions load promptly and can be opened and controlled instead of producing an unavailable-host error.