Codex Remote Control unstable / disconnecting across Android and iOS while Windows Desktop works normally

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

• #39947
• #39931
• #39913
• #39954
• #39907

Powered by Codex Action

ChatGPT Remote for Android cannot reach Windows host

Summary

ChatGPT Remote on Android lists the Windows host Jason1 but shows it offline and fails with:

Failed to connect to ChatGPT desktop. Make sure the ChatGPT desktop app is open, then try again.

The desktop app is open, awake, online, authenticated, paired, and internally reports Remote state connected. A phone retry produces no new Remote event in the desktop log.

Environment

• Windows ChatGPT package: OpenAI.Codex_26.818.3698.0_x64__2p2nqsd0c76g0
• Microsoft Store product: ChatGPT, 9PLM9XGG6VKS
• Installed package version: 26.818.3698.0
• Bundled Codex app-server version reported by the desktop: 0.149.0-alpha.4
• Controller: current ChatGPT Android app
• Failure reproduced: 2026-08-21 at approximately 20:10 AEST

Microsoft Store reports no upgrade currently available for this installation.

Reproduction

1. Open the current ChatGPT desktop app on Windows.
2. Enable Remote under Settings > Connections and pair the Android phone.
3. On Android, open Remote and select Jason1.
4. Tap Try again.
5. Android reports that it failed to connect; no corresponding phone-originated Remote event appears in the desktop log.

Desktop evidence

At startup, the desktop reports Remote enabled and initially connected:

remote_connections.connection_state_changed error=null hostId=local state=connected
remoteControl/enable ... errorCode=null

The same startup then changes the Remote manager to connection-failed because the desktop enables an experimental feature that its bundled app server no longer accepts:

Features enabled ... apps_mcp_path_override ...
remote_connections.connection_state_changed
error.code=connection-failed
message=ignoring invalid experimental feature enablement keys: apps_mcp_path_override
state=connected

The installed Codex runtime reports:

codex-cli 0.149.0-alpha.4
apps_mcp_path_override  removed  false

The packaged desktop maps Statsig gate 1663911278 to feature key apps_mcp_path_override. No occurrence of the gate value or feature name exists in user configuration or app state; it is enabled at runtime by the desktop feature evaluation.

Separate plugin metadata defect found during diagnosis

The global plugin catalog release below also contains an invalid 313-character plugin-level default prompt, while the desktop parser limit is 128 characters:

• Plugin ID: Plugin_271fcfe114788191b30908b85bd9ade6
• Plugin name: ngs-analysis
• Display name: Life Sciences NGS Analysis
• Release: 1.0.3

Locally shortening the generated manifest removed this prompt-limit error from fresh Remote startup logs, but Android Remote still failed. The online catalog also restores the malformed 313-character value at each startup. This catalog issue should be corrected upstream, but it is not sufficient to explain the remaining phone failure.

Requested OpenAI action

Please investigate the desktop/feature-rollout incompatibility for package 26.818.3698.0:

1. Disable or remove Statsig gate 1663911278 (apps_mcp_path_override) for app-server versions where the feature is marked removed, or ship a compatible desktop/app-server build.
2. Ensure a non-fatal config warning cannot mark the Remote host as connection-failed while its state is otherwise connected.
3. Correct the Life Sciences NGS Analysis 1.0.3 plugin-level default prompt to at most 128 characters.

Expected result

The Windows host should register as reachable through the secure Remote relay, and selecting Jason1 from Android should open the host’s chats rather than showing the desktop-connectivity error.

Official feature documentation: https://learn.chatgpt.com/docs/remote-connections

Same issue here.

Same as well. However, I'm using a Linux host. I have the same exact issues.

Same problem here. It all started on the afternoon of August 20, 2026, and the disconnects keep happening from time to time.

Same here. Short threads work, but not long threads. I also connect my android phone to Linux hosts, and it also cannot load long threads from them.

Same issues here Using android mobile Chatgpt app and Linux CLI instances hosted on VMs.

It's been working really well until recently but now there are two issues:
1) some threads won't load via remote. Seems to be longer threads
2) sporadically some hosts will show a red dot and be unable to connect to the mobile app. Occasionally if I restart the chatgpt it may fix it but it breaks again shortly after.

@tibo-openai — could you please take a look at this Remote Control regression?

This appears to be the clearest umbrella report, with several independent same-day reproductions: #39815, #39856, #39931, #39947, #39954, and #40008.

The common pattern is: the desktop/CLI host remains healthy and pairing often succeeds, but Android/iOS Remote disconnects, shows the host offline or “Transport unavailable,” or fails to hydrate longer threads. Multiple reporters say it began around August 20–21 and persists after restarting, re-pairing, clearing cache, and testing different devices/networks. Several traces show the Remote connection reaching initialize and then closing immediately on newer app-server builds.

An acknowledgment or status update would help users avoid destructive local troubleshooting while the regression is investigated.

Update after further testing:

From the evening of August 22 through the afternoon of August 23 (Asia/Taipei), Remote recovered to roughly 90% of its normal reliability. I was able to use it for several hours with almost no problems, so I initially believed the issue had been fully resolved.

However, later on August 23, the connection became unstable again. Many connection attempts now fail, and it may occasionally connect only briefly before becoming unreachable again.

Wi-Fi and 5G show the same behavior, while the Windows host remains awake, online, and fully usable locally.

I also no longer believe that long threads or image-heavy projects are the primary cause. Those same large projects, including projects containing many generated images, previously worked smoothly over Remote. The current behavior appears more consistent with an intermittent Remote transport or session-registration problem than a deterministic project-size or attachment limit.

I can reproduce a closely related failure with a macOS host and the ChatGPT iOS client. My diagnostics suggest that, at least in this case, the Remote transport remains healthy and the failure occurs while resuming/hydrating larger existing task histories.

Environment

• Host: macOS, ChatGPT desktop 26.818.41509 (build 6962)
• Bundled Codex app-server: 0.149.0-alpha.4.1
• Remote client: ChatGPT for iOS
• Observed: 25 Aug 2026 (Australia/Sydney)

Reproduction

1. Enable Remote and connect the iPhone to the Mac host.
2. Open an established Codex task with a large history.
3. The host and task list are visible, but opening the task produces “Error loading messages” / “This task couldn’t reconnect.”
4. Fully quitting and relaunching both apps restores access temporarily.
5. The problem returns; smaller tasks continue to load normally.

Diagnostic observations

• The Mac host remains connected: remoteControl/status/read and remoteControl/enable return successfully.
• No corresponding host/websocket disconnect appears after the restart.
• Failing rollout histories were approximately 45–73 MB; a smaller task of approximately 25.7 MB loaded successfully.
• The local logs contain repeated “Conversation state not found” and unknown-conversation events during the affected period.
• One hidden child history repeatedly failed local projection at an ordinal boundary (expected ordinal 1438, got 1437), leaving about 920 rollout lines / 4.59 MB unprojected.
• The local task data remains present and readable in the state DB, history DB, and rollout JSONL, so this does not appear to be local data loss.
• Re-pairing/restarting is not a durable fix.

This appears consistent with the issue's second proposed failure mode: existing-thread resume/history hydration, rather than basic host discovery or Remote transport failure.

Expected: large existing tasks load normally through Remote.

Actual: restarting briefly clears the symptom, then large established tasks fail again while smaller tasks still load.

I have intentionally omitted task names, IDs, account identifiers, and raw rollout contents, but can provide sanitized timestamps or log excerpts if maintainers need them.

Same issue, but on Mac desktop + iOS. Tried all the steps suggested but same result.

Same issue on IOS remote to windows. Worked perfectly until this week, now I can't get a reliable connection. When it does connect sometimes the chat is quite out of date.