[Linux][Remote Control] Android reaches initialize then disconnects after ~306 ms on Codex CLI 0.149.0

What version of Codex CLI is running?

codex-cli 0.149.0

What platform is your computer?

Linux 6.17.0-23-generic x86_64 x86_64

Ubuntu 24.04.4 LTS. The remote client is the ChatGPT Android app (exact Android/app build not captured).

What issue are you seeing?

An experimental Linux codex remote-control host enrolls successfully and remains connected to the relay, but an Android Remote client cannot establish a usable session.

The Android client reaches the Linux publisher and sends app-server initialize. On the normal attempts, a status event is emitted about 10 ms later and the remote connection closes about 306–309 ms after initialize. Two attempts closed essentially concurrently with initialize; the subsequent status message was dropped because the connection was already gone. None of the seven attempts reached thread/list.

This was reproduced immediately after eliminating an earlier stale-version condition: all legacy publishers were stopped, Codex was updated, and a single fresh publisher was started. Both the installed CLI and the actual executable behind the publisher were 0.149.0.

Fresh trace summary (UTC):

| Connection | initialize | Close | Outcome |
|---|---|---|---|
| 2 | 21:55:57.638864 | 21:55:57.944960 | closed after 306.1 ms |
| 3 | 21:56:02.963406 | 21:56:03.269704 | closed after 306.3 ms |
| 4 | 21:56:09.209705 | 21:56:09.209678 | close logged ~0.03 ms before request; status dropped |
| 5 | 21:56:15.149206 | 21:56:15.455494 | closed after 306.3 ms |
| 6 | 21:56:18.732406 | 21:56:19.040982 | closed after 308.6 ms |
| 7 | 21:56:23.136235 | 21:56:23.136165 | close logged ~0.07 ms before request; status dropped |
| 8 | 21:56:31.635628 | 21:56:31.942422 | closed after 306.8 ms |

Sanitized representative sequence:

remote connection accepted
app-server request: initialize
app-server status event
remote connection closed (~306 ms after initialize)

The fresh publisher stream contained no HTTP 401/403/409/503 errors or timeouts. The publisher stayed active and its relay TCP connection remained established after the Android attempts failed.

What steps can reproduce the bug?

1. Install Codex CLI 0.149.0 on Ubuntu 24.04.4 x86_64.
2. Run codex remote-control and wait until it reports that the machine is available for remote control.
3. Confirm there is only one publisher and that its executable is the 0.149.0 standalone binary.
4. In ChatGPT for Android, open Remote and select/open the already paired Linux host.
5. Observe that the Android client never establishes the session.
6. Inspect the publisher/app-server trace: initialize arrives, then the connection closes roughly 306 ms later (or closes before the response can be delivered), without reaching thread/list.

What is the expected behavior?

After initialize, the Android client should keep the connection open, proceed to thread/list, and display a usable Remote session for the host.

Codex doctor report

codex doctor --json reports overallStatus: ok on 0.149.0. Provider HTTP reachability succeeds, the Responses WebSocket handshake returns HTTP 101, no proxy is configured, and the state databases pass integrity checks.

Doctor reports the managed persistent background app-server as not running because this reproduction uses the foreground codex remote-control process, which launches its own app-server on a temporary Unix socket.

Additional information

• The successful fresh publisher connection was established at 2026-08-21 21:54:21Z. The first Android attempt began about 96 seconds later, so this is not a long-lived process surviving an upgrade.
• A first start returned the generic Remote control ... connection is errored message; the configured systemd user service retried three seconds later and successfully made the machine available. All Android attempts above occurred only after that successful start.
• This Linux signature closely matches the macOS trace reported in #39856: Android reaches initialize, then disconnects within a few hundred milliseconds, with some messages dropped after the connection closes. The parent issue is Windows-specific and labeled windows-os.
• #34721 describes a stale remote-control publisher after CLI updates. That condition existed initially here (0.144.6 publisher vs newer installed CLI), but this reproduction occurred after a clean restart with both publisher and CLI verified at 0.149.0.
• I am aware that the current Remote documentation lists macOS and Windows desktop hosts, and that Linux CLI Remote is experimental. This report is intended to capture the protocol-level Linux reproduction and cross-platform similarity; #38115 tracks formal Linux CLI host support.
• Existing pairing/enrollment state was retained. No database reset or re-pair was performed.
• Account identifiers, machine identifiers, connection tokens, and thread IDs have been omitted.