Remote control Windows WSL to Android not working at all

Still an issue

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

• #30791
• #30590

Powered by Codex Action

Did you fix it? it randomly started working today

Never mind it's back not working at all

Still not working at all - shows "Reconnecting..." on the android side and it says "Last connected 1m" on the Windows App side, so the app thinks it's working but it's not.

Worked for a few minutes today. Then back to Reconnecting.

Flashed my folders for a moment just now. Then gone.

Still not working

Still not working at all on 26.715.72359. I also verified that I can create other connections and that it still fails if I use a netbird (similar to tailscale) VPN.

Still not working

btw, this feature works 100% flawlessly using the Claude Windows desktop app + Claude Android app, so it's 100% a codex software issue, not an environment issue.

Still not working in 26.721.41059

Still not working in 26.721.81911

Still not working after voice update on Android

Switched to Windows native, reinstalled codex workspace and it worked. So this is a WSL problem possibly

Tried cutting the app out altogether and same symptoms

kendonb@kendonb:~/projects$ codex remote-control start
Starting app-server daemon with remote control enabled...
This machine is available for remote control as kendonb.
Daemon used app-server:
  path: /home/kendonb/.codex/packages/standalone/current/codex
  version: 0.146.0

Then paired then on Android it just says "Reconnecting to ChatGPT desktop" forever

Reported from GPT 5.6 Sol (apologies for the slop post)

I reproduced this against the current Android-to-WSL remote-control path. This is an initial-history timeout, not missing WSL port forwarding.

The Android client reaches and initializes the WSL daemon successfully. The daemon logs allocate a logical connection ID only after receiving initialize, so pairing and relay connectivity have already succeeded. Each Android connection then closes on an approximately 30-second cadence.

The next startup RPC is thread/list. I confirmed that sequence in the working native-Windows remote logs, then benchmarked the same request directly against the live WSL app-server Unix socket:

| Path | Initial thread/list time |
|---|---:|
| WSL, normal request (created_at, limit 50) | 26.188 s |
| WSL, identical request with useStateDbOnly: true | 0.069 s |
| Working native-Windows remote host | about 19 s |

The normal WSL request consumes nearly the entire mobile connection deadline before relay, segmentation and response overhead. Android then closes the connection and repeats the “Reconnecting to ChatGPT desktop” loop.

Why this installation exposes the problem:

• WSL contains 70,953 rollout JSONL files and 70,411 state-DB rows.
• The state database is approximately 4.5 GB.
• About 92% of the rollouts have source kind exec, which the default interactive-history request excludes.
• The normal listing path scans rollout JSONL files looking for qualifying sources, with MAX_SCAN_FILES = 10000, and then reconciles filesystem hits with the database.
• It returned only 37 of the requested 50 threads after 26.2 seconds.
• The indexed state-DB-only request returned 50 threads in 69 ms. Its serialized response was larger than the normal response, so payload size is not the cause.

Relevant implementation details:

• ThreadListParams.use_state_db_only explicitly bypasses filesystem scanning.
• The normal path invokes the filesystem-first scan and repair/reconciliation path in RolloutRecorder::list_threads.
• The scanner has MAX_SCAN_FILES = 10000.
• Omitted sourceKinds defaults to interactive sources in filters.rs, which makes a rollout store dominated by exec sessions especially expensive to search.

Recommended fix:

1. Have the Android client send "useStateDbOnly": true on the initial thread/list request and subsequent history pages.
2. Harden app-server by making remote-control history DB-first server-side, so older clients cannot put filesystem scan-and-repair work on the UI-critical RPC path.
3. If the database is empty or fails, perform the scan fallback outside the 30-second blocking connection path.
4. Add a regression fixture with more than 10,000 rollouts dominated by an excluded source kind; assert that the initial remote history page completes comfortably inside the client deadline.
5. Add remote-control instrumentation for connection/client identity, RPC method, request-to-response duration, response bytes/chunks and explicit close reason. The current logs only report that the logical connection closed.

There is already a close upstream precedent: d62353a, “Load local session pickers from the state DB first (#36378)”, makes the TUI resume/fork picker DB-first. The Android initial history request needs the corresponding behaviour.

I also found a separate takeover defect. After the native-Windows host had been active, starting the WSL remote server produced 127 HTTP 409 responses containing {"detail":"Remote app server already online"} over about 17 minutes before it was admitted. Windows and WSL had distinct enrollment IDs but the same account/server name. Stale ownership should expire or transfer much sooner, and the conflict should be surfaced clearly. This explains delayed WSL startup, but not the persistent reconnect loop after WSL successfully connects and receives Android clients.

The remote-control architecture uses an outbound secure relay, and the live WSL daemon is receiving the Android logical connections. No inbound WSL port forwarding is required.

Additional reproduction: native Windows host -> Android still fails on current builds (2026-08-21)

This reproduces on a native Windows Codex/ChatGPT Desktop host, not a WSL target.

Environment

• Desktop package: OpenAI.Codex 26.818.3698.0
• Bundled/user-executable CLI: codex-cli 0.149.0-alpha.4
• Host: Windows 11 25H2, build 26200.9168
• Mobile: Android (Samsung Galaxy S26 Ultra), ChatGPT updated from Google Play on 2026-08-21
• Workspace/session: native C:\... local Codex sessions

Reproduction

1. Previously paired mobile host began showing transport unavailable.
2. Fully restarted the desktop package. The restart also activated an update from desktop 26.810.7004.0 to 26.818.3698.0.
3. Revoked the stale mobile authorization and completed a fresh pairing.
4. Mobile automatically searched for GPT Desktop, then failed with: "Failed to connect to ChatGPT desktop. Make sure desktop is open and try again."
5. Updated ChatGPT from Google Play, force-stopped it, cleared its cache, reopened it, and retried.
6. Same failure. Re-pairing and another desktop retry do not help.

Sanitized desktop diagnostics

• Desktop app is open; package processes and app-server restarted cleanly.
• Current packaged backend command is:

codex.exe -c features.code_mode_host=true app-server --analytics-default-enabled

• No dedicated remote-control daemon/process appears in the process tree.
• Packaged codex.exe had 21 established HTTPS connections; Chromium NetworkService had 9.
• DNS/general internet connectivity healthy; OpenAI status operational.
• No explicit Windows Firewall block rule for ChatGPT/Codex.
• No matching Defender or Windows Application error events during pairing.
• Restart cleared 18 stale CLOSE_WAIT sockets, but the mobile failure persisted.
• No proxy environment variables or remote_control override in config.toml.
• PC clock matched authoritative Eastern time within approximately 3 seconds.

CLI findings

Attempting the apparent fallback:

codex remote-control start --json

returns:

Error: codex app-server daemon lifecycle is only supported on Unix platforms

Also:

codex features list

reports:

remote_control    removed    false

Interpretation

Pairing authorization completes, and the desktop has healthy ChatGPT/backend sockets, but the native Windows host never becomes reachable to Android. This appears different from the later WSL thread/list timeout evidence: the failure occurs at desktop-host connection/registration before any sessions are available.

Could maintainers confirm whether package 26.818.3698.0 is expected to launch or integrate a Windows remote-control host service, given that the bundled CLI fallback is Unix-only and the feature is reported as removed?

No account IDs, enrollment IDs, tokens, session IDs, or raw logs are included.