Windows Remote: QR pairing succeeds but Android clients cannot establish session (`nextConnectionCount=0`) on 26.818.31338

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

• #39817

Powered by Codex Action

Same failure on a macOS host (ChatGPT desktop 26.818.31338), and I can add the server-side piece this issue is missing: RUST_LOG=codex_app_server_transport=trace on the publisher shows the Android client does reach the app-server and completes initialize successfully — then closes the connection ~250 ms later without sending any further RPC and without any error. So pairing works, routing works, the server answers correctly, and the client walks away.

Representative trace (one of 22+ identical attempts on 2026-08-21, times UTC):

05:14:23.581 INFO initialize connection_id=4 api_version="v2"
             client_name="codex_chatgpt_android_remote" client_version="dev"
05:14:23.581 INFO initialize ... close time.busy=652µs time.idle=159µs   <- served OK, no error
05:14:23.830 INFO client_tracker: forwarding remote control connection closed  <- client gone 249 ms later

One attempt closed so fast the server logged dropping message for disconnected connection — the client vanished before the response was even delivered. Meanwhile a Codex Desktop 26.810.52044 (Windows) controller session worked normally through the same publisher at the same time (getAuthStatus, thread/list, process/spawn), so the enrollment, account, relay path, and publisher are all healthy.

Ruled out on my side (identical failure in every combination):

• app-server version: 0.145.0, 0.149.0-alpha.4 (embedded), 0.149.0 stable, 0.150.0-alpha.2 (published 2026-08-21) — all reproduce
• pairing: removed/re-paired twice, remoteControl/pairing/start succeeds
• Android app: reproduced on the pre-2026-08-20 build and the current build, and after a full Clear data reset (fresh sign-in, fresh device keys)
• publisher registers online with no 409 conflicts; backend __slingshot_backend_initialize__ session initializes normally

Regression window: worked daily until 2026-08-18, broke ~2026-08-19 with no local changes. Given #39815 shows /wham/tasks/list returning 503 in the same window, this looks like a backend/Android-side regression on the wham remote-control path rather than anything host-side.

Publisher identifiers if it helps locate server logs: server_id=srv_e_6a2d04ce9e3c832ca616b5e33a3a90c7, environment_id=env_e_6a2d04ce9e30832cb4f8bad051a4b7e7, installation db42a3da-99f9-4fa8-8a89-bba3da9fff75, Android attempts 2026-08-21 05:14–05:22 UTC. Happy to provide full traces.

I can reproduce a closely related Windows/Android Remote failure on Codex Desktop 26.818.31338, with a useful A/B control that may help isolate the fault.

A/B results

Same ChatGPT account and same Android client:

• Windows Host A: Android Remote stays unavailable/red and reports that it cannot connect to ChatGPT Desktop.
• Windows Host B: Android Remote connects normally/green.
• iPad mini -> Windows Host A: connects normally.

So the affected Windows host is reachable through Remote from iPadOS, while the same Android client can successfully use Remote against a different Windows host. This argues against a general Android account/network problem or a generally broken Windows Remote host.

Desktop version

Both Windows hosts were brought to the same ChatGPT/Codex Desktop version:

26.818.31338

The failure persisted only on Host A after the versions matched.

Pairing / authorization behavior on affected Host A

• QR pairing succeeds.
• Desktop shows the Android device as authorized/recently connected.
• Desktop setup can show Connected.
• Android can see the host, but the host remains red/unavailable and the Remote session cannot be established.
• Reinstalling the Android app did not help.
• Wi-Fi and cellular were both tested.
• Two Android devices showed the same failure on Host A.

Host-state reset already tested on affected Host A

After fully quitting ChatGPT Desktop and backing up ~/.codex, I tested a targeted Remote reset:

1. Cleared remote_control_enrollments in state_5.sqlite.
2. Re-paired: still failed.
3. Rotated the local installation_id.
4. Removed electron-local-remote-control-installation-id and electron-local-remote-control-environment-id from .codex-global-state.json.
5. Cleared remote_control_enrollments again and re-paired with a fresh QR code.
6. Desktop again reported the device as connected, but Android still showed the host as unavailable/red.
7. iPad mini continued to connect to the same affected host successfully.

Local load check

The affected host has only about 249 session/rollout files (about 1.4 GB total). codex.exe was around 167 MB working set during the check, so this does not look like the very-large-thread-count timeout case.

Why this may be useful

The strongest discriminator is:

• Android -> Host A: fails
• Android -> Host B: works
• iPadOS -> Host A: works

This suggests a host-specific Android Remote control-plane/session mapping issue (or Android-specific host/environment state) rather than simple pairing failure, desktop-offline state, or a general transport/network failure.

No account IDs, tokens, QR contents, environment IDs, or private project data are included here. I can provide additional sanitized diagnostics if maintainers identify a specific log or Remote endpoint/state to inspect.

I can reproduce the same Windows/Android Remote failure, and I have one additional diagnostic that may help narrow the failure stage.

Environment

• Windows ChatGPT/Codex Desktop updated from 26.818.2872.0 to 26.818.3698.0
• Android 13 client
• QR pairing succeeds and the Android device appears in Desktop > Connections > Control this PC
• Android can see the Windows host, but it stays red/unavailable and eventually shows that it cannot connect to ChatGPT Desktop

Important live-trace result

I monitored the Windows Remote/app-server logs live while pressing Retry on Android (2026-08-21 ~08:47:31–08:48:45 UTC).

In this case, the Android connection attempt did not reach the PC Remote/app-server layer at all:

• no attach
• no Remote RPC
• no environment routing event
• no authentication request
• no 401, 403, 409, timeout, ID mismatch, or disconnect associated with the attempt

The traffic during the retry window was only local isRemoteHost=false activity.

At the same time, read-only backend state showed:

• the Windows Remote environment was online=true, busy=false
• the Android client was enrolled and had been seen by the backend during the same period
• the PC's local environment/installation identity matched the backend state; no local identity mismatch was found

So the Android -> backend path appears alive, and the Windows host is registered online, but the attach request is not being delivered to the host.

There was an earlier startup/update event where the new app-server briefly hit 409 Conflict — Remote app server already online, but after restarting the desktop app only one app-server remained, Remote reported connected, and no further 409s occurred. The Android failure still persisted after that cleanup.

Additional troubleshooting already tried:

• fully restarted ChatGPT/Codex Desktop
• force-stopped the Android ChatGPT app
• cleared Android app cache
• verified the PC remains awake and online
• verified Remote connections are allowed and the Android device is authorized

This looks consistent with a stale host/presence mapping or control-plane/relay routing problem between the Android client and the currently-online Windows environment. It may be a slightly different failure mode from cases where Android reaches initialize and then disconnects immediately: here the retry produced no host-side attach/initialize activity at all.

I can provide additional sanitized timestamps/log excerpts if maintainers want a specific Remote endpoint or state checked.

I am experiencing the same issue on Windows 10 with an Android client. Pairing succeeds, both devices are visible in their respective connection settings, but Android cannot establish the Remote session.

Environment:

• Windows 10 Pro 22H2, x64
• Windows AppX package: OpenAI.Codex 26.818.3698.0
• Android 15, Samsung SM-G996B
• ChatGPT Pro

My desktop logs contain additional backend evidence:

HTTP 409 Conflict
{"detail":"Remote app server already online"}

Only one local codex.exe app-server process was running when this occurred.

Feedback/session ID:

no-active-thread-01a02460-9d88-7e31-8cb9-f49da4fd550c

Request ID:

6c91ce0d-dd22-4ea3-a196-72751f183506

The issue persists after restarting both applications, signing out and signing in again, revoking and recreating the QR pairing, switching networks, and verifying DNS/TCP 443 connectivity and the absence of a WinHTTP proxy.

The HTTP 409 response suggests that the backend retains a stale Remote app-server registration/session and rejects the current Windows host as already online.

Independent macOS + Samsung/Android reproduction matching the post-pairing transport failure described here.

Environment

• macOS 26.6.2 (25G83)
• ChatGPT/Codex Desktop 26.818.22352 (bundle 6872)
• Samsung SM-S938B
• Android 16
• Same ChatGPT account/workspace on both devices

Observed behaviour

• “Control this Mac” enables normally.
• QR pairing completes successfully and the Android device is authorised.
• Android can identify the Mac, but attempting to connect reports:

Failed to connect to ChatGPT desktop. Make sure ChatGPT desktop is open and try again.

• ChatGPT Desktop is open, the Mac is awake, and the host Remote WebSocket remains connected.
• During each Android retry, the desktop receives a Remote connection and an initialize request.
• initialize is processed, but the Android Remote transport closes within the same second without progressing to a usable task/session request.
• This reproduced across several consecutive connection attempts.

Troubleshooting completed

• Uninstalled and reinstalled ChatGPT on Android.
• Restarted the Mac and ChatGPT Desktop.
• Revoked the Android device and completed a fresh QR pairing.
• Tested over normal Wi-Fi.
• Disabled Wi-Fi and retried over Android mobile data.
• Confirmed the Mac firewall is disabled and system sleep is not interrupting the host.

The result is identical over both networks. Because QR enrolment succeeds and the Android request reaches and initialises against the Mac before immediately disconnecting, this does not appear to be a local-network, firewall, sleeping-host, or “desktop app not open” problem.

This appears consistent with an Android Remote client or backend control-plane/relay regression occurring after successful pairing and host routing.

Privacy

Account/workspace identifiers, installation/server/environment IDs, QR contents, IP addresses, local paths, task contents, and raw logs are intentionally omitted. Sanitised timestamps or targeted log events can be supplied if a maintainer requests them.

Additional reproduction from another affected Windows + Android user. This appears to match the total Remote-connectivity failure in this issue, with a separate longstanding desktop→mobile sync problem.

Current blocking regression

• Remote had at least partial functionality earlier on 2026-08-21.
• The Windows Codex/ChatGPT desktop app then offered an in-app update; after installing that update, Android Remote stopped being usable.
• Android still sees the paired Windows host in Remote.
• Selecting the host shows “Looking for ChatGPT desktop…” and then “Failed to connect to ChatGPT desktop. Make sure the ChatGPT desktop app is open, then try again.”
• The desktop app is open and signed into the same account.
• Revoking Android access and pairing it again succeeds, but does not restore a usable Remote session.
• Force-stopping the Android ChatGPT app does not help.
• The user can re-establish/see the pairing, but cannot actually enter Codex Remote or load/use the Windows host at all.
• The exact Windows Codex build was not captured yet; it was the update offered by the desktop app on 2026-08-21.

This is the primary issue and is currently blocking all remote Codex work for the user.

Separate pre-existing sync symptom

This existed before the current total connection failure:

• A Codex thread created on Android appears on the Windows desktop.
• A Codex thread created on Windows does not appear on Android.
• Windows-created Codex project folders also do not appear on Android.
• So thread/project propagation has historically been asymmetric (Android → Windows works; Windows → Android does not).

The Android Remote UI also shows two entries for the same Windows host name, but those duplicate host pills have existed for a while and did not begin with today's regression, so they may be unrelated/stale registration state rather than the trigger.

Sanitized screenshots of the exact Android Looking for ChatGPT desktop… → Failed to connect to ChatGPT desktop sequence are available if maintainers need them. The user is experiencing significant productivity impact because Remote access is part of their normal workflow away from the PC.

Please prioritize the total Android→Windows Remote connection regression separately from the older thread/project indexing problem.

Confirming the same issue on Windows with a newer desktop build: Codex Desktop 26.818.4152.0.

Android displays “Transport unavailable” when connecting to the Windows host. Troubleshooting already completed:

• Uninstalled and reinstalled the ChatGPT Android app.
• Left the Android beta channel and installed the current stable release.
• Uninstalled and reinstalled Codex Desktop on Windows.
• Signed in and paired again; the problem persists.

Sanitized Windows-side checks after reinstall:

• Codex Desktop and its local app-server start normally.
• Remote enrollment is present and enabled; it refreshed successfully after reinstall/startup.
• The local Codex state database passes PRAGMA quick_check (ok).
• remoteControl/pairing/start completes with errorCode=null.
• Repeated remoteControl/client/list requests complete with errorCode=null.
• While Android attempts to connect, the desktop repeatedly logs:

refresh_remote_control_started previousConnectionCount=0
reconcile_completed creationFailureCount=0 nextConnectionCount=0 previousConnectionCount=0
refresh_remote_control_completed autoConnectConnectionCount=0 nextConnectionCount=0 previousConnectionCount=0

The Windows host can also resolve and reach the ChatGPT relay endpoint over TCP 443. This appears to be the same post-pairing live-session failure described here, and confirms that it still reproduces on desktop build 26.818.4152.0.

A verified workaround restored Remote on the affected Windows host:

1. Revoke all authorized devices on the affected host.
2. Turn off Allow connections and fully quit the desktop app.
3. Remove the host from the mobile app, then use Sign out of all devices for the ChatGPT account.
4. Keep both the desktop and mobile apps completely closed for a full 15 minutes.
5. Open/sign in to the desktop host first, re-enable Remote, and pair only one mobile device. Add any other devices one at a time afterward.

Reinstalling the desktop/mobile apps, repeatedly scanning new QR codes, and resetting local .codex/database state did not fix the issue. The full 15-minute idle period was the step that made the recovery succeed.

A stale server-side Remote session or registration that needed time to expire would fit the symptoms, but that is only a hypothesis—not a confirmed root cause.

Codex Remote Control incident report

Report type: public, fully redacted

Title: Codex Remote Control suddenly became offline on Windows and Android can no longer pair

Captured: 2026-08-22T10:54:27+09:00 / 2026-08-22T01:54:27+00:00

Summary

Codex Remote Control worked immediately before the incident. It then became red/offline in ChatGPT for Android. The Windows Codex Desktop app remains healthy, local threads open normally, and local work continues. Remote Control remains enabled and the Windows host has a valid local enrollment. The current host Remote WebSocket is connected, but Android Remote connections fail to become usable and fresh QR pairing does not complete.

This evidence strongly isolates the failure to the Android/controller-to-Remote-session path, controller enrollment, or server-side Remote relay/session state. It does not support "Codex is not running," "app-server is absent," or a general PC network outage.

Environment

• Host: <WINDOWS_HOST>
• OS: Microsoft Windows 11 Home 25H2, build 26200.9168, x64
• Microsoft Store package: OpenAI.Codex 26.818.2872.0 x64
• Desktop internal client version observed in app-server logs: 26.818.22352
• ChatGPT.exe file/product version: 151.0.7922.170
• Embedded app-server / codex runtime: 0.148.0-alpha.21 (version string recovered from the packaged executable; direct execution from WindowsApps was denied)
• User-local Codex CLI: codex-cli 0.144.6
• Install location: C:\Program Files\WindowsApps\OpenAI.Codex_26.818.2872.0_x64__2p2nqsd0c76g0
• User data/log location: %USERPROFILE%\.codex
• Remote client: ChatGPT for Android (exact Android build unavailable from Windows-side diagnostics)

Confirmed behavior

1. Remote worked immediately before the incident.
2. Android now shows the Windows host red/offline.
3. Codex Desktop itself is working.
4. Existing local Codex threads open and continue normally.
5. The app-server process is running as codex.exe -c features.code_mode_host=true app-server --analytics-default-enabled.
6. Remote Control is enabled in local state.
7. The Windows app can generate a fresh Remote pairing QR code.
8. Android cannot complete re-pairing or establish a usable Remote session.
9. A full Desktop/app-server restart did not fix the issue.
10. On Windows, codex remote-control start returns: codex app-server daemon lifecycle is only supported on Unix platforms.
11. No local identity, enrollment, authentication, DB, firewall, or OS reset was performed.

Host and Remote evidence

• Running app-server PID and process tree were captured in 03_PROCESS_TREE.txt.
• state_5.sqlite contains one enabled Remote host enrollment for the Codex Desktop client. Account/server/environment identifiers are hashed in the evidence set.
• Latest host Remote WebSocket event is Connected: Live diagnostic read observed Connecting -> Connected at 2026-08-22 10:45:14 JST / 01:45:14 UTC; the connection to wss://chatgpt.com/backend-api/wham/remote/control/server succeeded..
• In the failure window, Android-named Remote traffic reached the app-server. The app-server recorded 22 initialize requests, 21 Remote connection-closed events, and 9 messages dropped because the destination connection had already closed.
• A current retry sequence reached initialize and once thread/list; many other connections closed in the same second, sometimes before an initialization response could be delivered.
• Earlier Android Remote RPC activity exists on Aug 11, 12, and 18, showing that this installation previously supported a working Android Remote session.
• Two host WebSocket 409 "Remote app server already online" events occurred earlier on Aug 21, but each recovered to Connected within seconds. The current incident persists after that recovery and after a full Desktop restart.
• No Remote-transport 401, 403, 429, or 5xx match was found in the retained last-seven-day Remote transport log subset.

Network evidence

• The running ChatGPT.exe and codex.exe processes have established outbound TCP 443 connections.
• DNS resolves chatgpt.com and api.openai.com.
• TCP 443 tests to both hosts succeed.
• The Remote host WebSocket itself reconnected successfully.
• An unauthenticated HTTPS HEAD returning 403/421 is application-layer reachability evidence only; it is not treated as a service health response.

Windows event evidence

• The Store package update from 26.814.5167.0 to 26.818.2872.0 was staged on Aug 21. Registration was initially deferred with 0x80073D02 because the old app was running, then completed later that day.
• No Codex/ChatGPT application crash was identified in the captured event subset.
• One unrelated Tcpip UDP ephemeral-port allocation warning was present; the Remote path uses a successful TCP/TLS WebSocket and this warning is not considered causal.
• Update timing is a correlation only, not proof of causation. Current official issues include comparable failures across Windows, macOS, and Linux hosts.

Diagnosis

Root-cause confidence: MEDIUM-HIGH for Remote controller/relay/session-path regression; LOW for exact component.

The Windows host is enrolled, enabled, online, and connected to the Remote relay. Local Codex and app-server operation are normal. Android-originated Remote transports reach the host but close during or just after initialization, and new pairing does not restore a usable controller session. This is most consistent with an Android Remote client regression, a server-side relay/controller-enrollment/session-state regression, or an incompatibility between the current Remote client and app-server protocol. The exact boundary cannot be proven from local host logs alone.

Separate stale rollout-path warnings exist for three old thread records, but local thread listing works and the host is red/offline before a specific thread is opened. Those warnings are not sufficient to explain the Remote-host availability failure.

Requested OpenAI action

Please investigate the server-side Codex Remote relay, controller enrollment, host enrollment, and Remote session state.

If necessary, reset only the Remote-related server-side state.

Do NOT delete or reset Codex threads, tasks, projects, authentication, or local work.

Please also inspect why codex_chatgpt_android_remote connections close during or immediately after initialize, and why a fresh QR flow does not yield a usable Android controller while the host WebSocket remains Connected.

Local safety statement

• Destructive changes: NONE
• Threads deleted: NONE
• Remote enrollments deleted: NONE
• Credentials changed: NONE
• Firewall/Windows settings changed: NONE
• Codex/ChatGPT reinstalled: NONE
• Secrets included: NONE

I can reproduce this on a Windows host, and the local app-server log provides a before/after comparison that corroborates the Android-side disconnect reported above.

Environment

• Host: Windows x64, build 26200.9168
• ChatGPT/Codex Desktop UI: 26.818.31338
• Windows AppX package: 26.818.3698.0
• Bundled app-server: 0.149.0-alpha.4
• Client: ChatGPT Android 1.2026.223 on Android 16
• Same ChatGPT account/workspace on both devices

Reproduction after a clean restart

I fully quit the desktop app and its Codex processes, relaunched it, revoked the Android authorization, and paired again with a fresh QR code. Pairing succeeded, the Android device appeared in the desktop's authorized-device list, and the Android app could discover the host. Selecting the host still failed.

The host-side Remote relay was connected. Each Android attempt reached the app-server and sent initialize, but the transport closed immediately afterward without any subsequent RPC from that connection ID.

Representative sanitized trace, UTC:

2026-08-21 05:29:45.605 app-server request: initialize connection_id=ConnectionId(2) request_id=Integer(35)
2026-08-21 05:29:46.075 forwarding remote control connection closed transport event connection_id=ConnectionId(2)

2026-08-21 05:30:00.312 app-server request: initialize connection_id=ConnectionId(4) request_id=Integer(37)
2026-08-21 05:30:00.653 forwarding remote control connection closed transport event connection_id=ConnectionId(4)

2026-08-21 05:31:41.346 app-server request: initialize connection_id=ConnectionId(9) request_id=Integer(42)
2026-08-21 05:31:41.635 forwarding remote control connection closed transport event connection_id=ConnectionId(9)

There were eight consecutive attempts (ConnectionId(2) through ConnectionId(9)). Every connection closed 0-526 ms after initialize. None sent thread/list, config/read, or any other post-initialize RPC. No 401, 403, 409, or explicit host-side transport/authentication error appeared in the fresh test window.

Before/after control on the same host

The same host log shows a previously working Android Remote session on 2026-08-18. That client identified itself as codex_chatgpt_android_remote, initialized successfully, and then continued normally:

2026-08-18 13:59:19.479 initialize
2026-08-18 13:59:20.111 thread/list
2026-08-18 13:59:35.823 config/read
2026-08-18 13:59:35.823 mcpServerStatus/list
2026-08-18 13:59:35.826 plugin/list
2026-08-18 13:59:35.826 skills/list
2026-08-18 13:59:36.237 fs/readFile
2026-08-18 13:59:36.237 configRequirements/read
2026-08-18 13:59:36.582 model/list

This narrows the current failure to the stage after pairing, discovery, relay routing, and successful delivery of initialize, but before the Android client begins normal app-server RPCs. It also distinguishes this case from a large thread/list response failure because the failing client never requests thread/list.

The excerpts are sanitized. No account, server, environment, installation, device, token, hostname, username, local path, QR, or project identifiers are included. I can provide additional targeted sanitized trace data if maintainers specify what they need.

Resolution update

Resolved after updating the Windows AppX package to 26.818.5229.0 (internal desktop client 26.818.41509).

On the same host and Android client, the app-server now proceeds normally through:

initialize
thread/list
config/read
skills/list
plugin/list
model/list

The immediate post-initialize transport close no longer occurs. This strongly suggests a fix in the newer desktop package or a concurrent backend change; I cannot distinguish those two possibilities from host-side logs alone.

Seconding the recovery sequence reported above. On the affected Windows host, I used Windows Settings > Apps > Installed apps > ChatGPT/Codex > Advanced options > Reset to perform a full Windows app reset. I then left the desktop app closed for approximately 15 minutes, reopened it, signed back into the same ChatGPT account, re-enabled Remote, and established a fresh mobile connection. Android then connected successfully and no longer displayed “Transport unavailable.”

Before this, reinstalling both apps, leaving the Android beta, and repeating the pairing flow had not resolved the problem. The successful recovery therefore followed this sequence: full Windows app reset → approximately 15-minute idle period → fresh authentication → new Remote connection.

I cannot isolate which step was causal or confirm that server-side state expired during the wait, and I do not yet know whether the recovery will remain durable. However, this independently matches the reset/idle-period recovery pattern reported above.

Update — issue persists on Codex Desktop 26.820.71523 with captured reconnect cycle

The problem is still present on a newer Windows Codex Desktop build: 26.820.71523.

This time the reconnect event was captured in the structured logs_2.sqlite telemetry rather than the normal desktop text log.

Current host state

• Windows host
• Codex Desktop: 26.820.71523
• Exactly one codex.exe ... app-server process was present at the time of the failure
• No duplicate app-server process was found
• No 409 Conflict / Remote app server already online
• No initialize_handshake_timeout
• No authentication failure observed

Captured reconnect sequence

At 2026-08-27T07:14:08Z, while Remote still reported itself as Connected, the Remote WebSocket connection worker ended:

app-server remote control websocket connection cycle ended
connection_end_reason=ConnectionWorkerStopped
current_status=Connected
desired_state=Enabled

Codex immediately started reconnect attempt 1:

starting app-server remote control websocket connection cycle
reconnect_attempt=1
current_status=Connected

The status then changed:

previous_status=Connected
next_status=Connecting

Codex refreshed the Remote server token and reconnected successfully roughly 3 seconds later:

previous_status=Connecting
next_status=Connected

connected to app-server remote control websocket
websocket_url=wss://chatgpt.com/backend-api/wham/remote/control/server

Immediately after reconnect, the backend sent a fresh Remote initialize request:

app-server request: initialize
connection_id=ConnectionId(2)
request_id=String("__slingshot_backend_initialize__")

and Codex reported:

remoteControl/status/changed targeted_connections=1

Later, at 2026-08-27T07:24:11Z, the host logged:

forwarding remote control connection closed transport event
connection_id=ConnectionId(1)

Interpretation

This capture appears different from the duplicate/orphaned app-server failure mode because only one app-server process was running and there was no 409.

The failure instead looks like an intermittent Remote WebSocket/session lifecycle instability where the connection worker stops even while Codex still considers Remote Connected, followed by an automatic reconnect and fresh Remote initialize.

The underlying Codex Desktop/app-server remained functional throughout. This matches the broader pattern where local Codex work continues while the interactive mobile Remote session drops/reconnects.

Sanitized excerpts only: account IDs, installation IDs, environment/server IDs, local paths, tokens, and device identifiers have been omitted.