remote-control relay connection silently disconnects after 20–55 minutes without auto-reconnect (WSL2) #26786

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   remote

   on Jun 6, 2026
2. github-actions commented on Jun 6, 2026

   

   github-actionsbot

   on Jun 6, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Remote control presence decays on backend while client websocket stays fully connected (device shows stale on phone/web despite healthy local connection) #25984

   Powered by Codex Action
3. wananing commented on Jun 25, 2026

   

   wananing

   on Jun 25, 2026

   More actions

   I looked at this against current upstream/main (f2f80ef442ff84612004bad064991283eb17cdb5) and I think the first PR, if maintainers want one, should stay narrowly scoped to Remote Control relay transport recovery inside the existing app-server process.

   I do not want to claim this covers every symptom in this issue yet. In particular, if remoteControl/status/read times out and an unrelated local RPC such as config/read or thread/list also times out at the same time, that points above the relay WebSocket layer, likely in the app-server RPC dispatcher/local transport path, and should be debugged separately.

   For the transport/liveness side, I have a deterministic local fake-relay regression test that exercises this sequence:

   1. Start Remote Control against a local fake relay.
   2. Complete enrollment and establish the first WebSocket.
   3. Observe connected.
   4. Keep the WebSocket/TCP connection open but stop producing pong frames.
   5. Advance past the pong timeout.
   6. Assert status leaves connected and becomes connecting.
   7. Assert a second relay WebSocket handshake is established.
   8. Assert a remote initialize message on the second generation still reaches the transport.

   I also added a smaller unit test for the lifecycle edge case where one connection worker stops while the sibling worker is still stuck during generation drain. The important assertion there is that Remote Control publishes a non-connected state before drain completes, so local status does not remain stale as connected after the generation is already known to be dead.

   The local patch is intentionally limited to codex-app-server-transport Remote Control code:

   • do not restart app-server or the daemon;
   • do not touch daemon ownership/unmanaged-process behavior;
   • do not delete or recreate enrollment;
   • do not rotate installation_id;
   • do not add a public RPC;
   • preserve long-lived RemoteControlWebsocket state across reconnects;
   • when a connection worker stops unexpectedly, publish connecting, cancel only the current WebSocket generation, and rely on the existing reconnect loop to create the next generation.

   Validation on f2f80ef442ff84612004bad064991283eb17cdb5 plus the local patch:

   just test -p codex-app-server-transport \
     remote_control_transport_reconnects_after_disconnect \
     remote_control_transport_reconnects_after_pong_timeout \
     run_connection_marks_status_connecting_when_worker_stops_before_drain
   
   3 tests run: 3 passed
   

   just fix -p codex-app-server-transport
   
   passed
   

   cargo fmt -- --config imports_granularity=Item completed locally; stable rustfmt warns that imports_granularity is nightly-only.

   I also ran the full crate test:

   just test -p codex-app-server-transport
   
   125 tests run: 124 passed, 1 failed
   

   The one failure is transport::remote_control::tests::remote_control_waits_for_account_id_before_enrolling, timing out in the auth-change wakeup path:

   auth change should wake remote control before the retry delay: Elapsed(())
   

   That failure is reproducible for me outside the new pong-timeout/connection-generation path, so I am treating it as a separate timing issue rather than evidence against the relay-generation recovery test.

   Would a maintainer be willing to invite a focused PR for this transport-scoped approach? If not, the next diagnostic data I would collect for this issue is the failure-time split between remoteControl/status/read and an unrelated local RPC such as config/read, to determine whether the stuck state is confined to Remote Control or affects the app-server dispatcher more broadly.
4. mjzcng commented on Jul 8, 2026

   

   mjzcng

   on Jul 8, 2026

   More actions

   I do not think this solves the real transport auto-reconnect bug described here, but for day-to-day use I found it helpful to have a tiny wrapper that makes the CLI remote-control app-server easier to restart and keep around as a background process:

   https://github.com/mjzcng/codex-cli-mobile-pairing

   The main flow is:

   npx codex-cli-mobile-pairing start
   npx codex-cli-mobile-pairing status
   npx codex-cli-mobile-pairing restart
   npx codex-cli-mobile-pairing logs

   It uses the experimental app-server pairing APIs to generate a manual pairing code, then leaves the backing codex app-server running. For this issue specifically, restart is just a workaround when the mobile side goes stale; the proper fix still needs to be in the relay transport / app-server recovery path you outlined.