Codex mobile remote connection cannot be paired again after removing device on Mac

also cant reconnect from cli

Same issue.

I removed it because while it was initially working, <12 hours later it prompted to "reconnect" on mobile, and the button did nothing.

Can't see a way to remove the connection from mobile and set it up again, so I'm stuck.

Exact same issue on macOS + iOS. Latest versions of codex/chatgpt app on both.

Same here, it blocks me from using Codex on mobile, is there an estimation on when it will be fixed? Thanks

Same here

Same problem on mac+iOS, latest versions. I still can see latest threads, though. But I cannot send any message, and recieve this mistake. Same situation: paired successfuly, unpaired from mac and stucked on that. QR is not halping, cannot removeold connection from iPhone

<img width="1290" height="384" alt="Image" src="https://github.com/user-attachments/assets/740eb52a-4a90-4067-9de0-902fdaac2e03" />

Did anyone find a workaround?

I personally am waiting for a fix from the dev because the only thing that can really solve the situation is this.

I’m sharing almost every day on x to make it see and notice, it’s an important bug

I've hit this too. Sad because I really want to use remote control!

Same issue here as well

Same here. In mobile ChatGPT app it's possible to edit connection, there is no way to delete it.

Same failure mode here after local stale-state cleanup, server-side environment cleanup, and ChatGPT iOS reinstall.

Environment:

• macOS 15.x, Apple Silicon
• Codex Desktop App 26.513.31313
• bundled app-server 0.131.0-alpha.9
• ChatGPT iOS app was deleted and reinstalled, not offloaded

Observed:

• Mobile originally showed a stale/offline Mac host.
• Codex Desktop showed no devices under "Devices that can control this Mac".
• Re-scanning QR did not create a mobile client enrollment.
• After deleting the stale server environment, mobile can see the fresh renamed host, but pairing still does not create a client.

Evidence:

• GET /backend-api/wham/remote/control/clients?limit=100 keeps returning {"items":[],"cursor":null}.
• GET /backend-api/codex/remote/control/environments?limit=100 initially had one stale/offline environment.
• DELETE /backend-api/codex/remote/control/environments/{env_id} removed it successfully.
• After restarting Codex Desktop, a fresh environment appears and can be seen on mobile.
• However, clients remains empty and local client enrollment remains null.
• Reinstalling ChatGPT iOS and retrying did not change this.

Conclusion:

This no longer looks like only local stale state. The desktop environment is discoverable, but the mobile QR/approval flow never creates a remote-control client enrollment.

I was able to get past this issue and properly reconnect it by:

1. Revoke access in the codex desktop app Connections settings
2. Uninstall and reinstall the ChatGPT mobile app fully
3. Open the Codex mobile app section and the mobile pairing modal re-appears and worked to repair the connection

Following this, my previous connection in the app restored to connected and the desktop app showed properly supplied access in Connections settings.

I was able to get past this issue and properly reconnect it by: 1. Revoke access in the codex desktop app Connections settings 2. Uninstall and reinstall the ChatGPT mobile app fully 3. Open the Codex mobile app section and the mobile pairing modal re-appears and worked to repair the connection Following this, my previous connection in the app restored to connected and the desktop app showed properly supplied access in Connections settings.

Issue is fixed!

Just install 0.132.0

> I was able to get past this issue and properly reconnect it by: > > 1. Revoke access in the codex desktop app Connections settings > 2. Uninstall and reinstall the ChatGPT mobile app fully > 3. Open the Codex mobile app section and the mobile pairing modal re-appears and worked to repair the connection > > Following this, my previous connection in the app restored to connected and the desktop app showed properly supplied access in Connections settings. Issue is fixed! Just install 0.132.0

It’s not fixed yet the problem is there, you’ve found a way to overcome it.

My case was a bit different, I did not see the phone connection in the Desktop App while it kept showing it in the phone. Unmarking and marking again "Allow this device to be discovered and controlled" in the Desktop App connections settings worked for me to restart the connection. Would be nice if there was a way to remove connections from the ChatGPT ios app side, it would be way more straight forward to reproduce a connection.

try run codex remote-control stop
then run codex remote-control start

figured it out myself by poking around.

I’m seeing what looks like the same stale Codex Mobile / Remote Control state, with one additional migration-related detail.

Summary

I migrated from a MacBook Air to a MacBook Pro using Apple Migration Assistant. I wanted to preserve my Codex projects, conversations, and local state. The migration did preserve my Codex projects/history, but Codex Mobile remote control became stuck afterward.

Current behavior:

• After the migration, both the original MacBook Air and the migrated MacBook Pro initially showed that they were connected to the same iPhone in their Codex Desktop connection settings.
• The iPhone ChatGPT app, however, only showed one Codex Desktop connection: macbook-air-2.local.
• That old/stale connection is offline/unusable.
• I went back to the Codex Desktop app on the original MacBook Air and removed/revoked the iPhone from the MacBook Air side.
• Even after removing the iPhone from the MacBook Air Codex client, the iPhone ChatGPT app still continued to show the stale macbook-air-2.local connection.
• I cannot remove/delete that stale connection from the iPhone app.
• Reinstalling ChatGPT on iPhone and signing in again does not remove it.
• I cannot re-bind the iPhone to the original MacBook Air anymore.
• I also cannot bind the iPhone to the migrated MacBook Pro.
• When I try to set up the MacBook Pro again, the mobile flow eventually fails with: Setup failed / Couldn't finish secure setup. Try again.

Environment

• Migration path: Apple Migration Assistant from MacBook Air to MacBook Pro
• Stale mobile host shown on iPhone: macbook-air-2.local
• macOS on the MacBook Pro: 26.5 build 25F71
• Codex App: 26.527.31326 build 3390
• Codex CLI: 0.135.0
• Plan: ChatGPT Pro
• Mobile device: iPhone
• iOS: 26.5
• ChatGPT iOS app: 1.2026.139 (26320156439)

What I tried

• Removed/revoked the iPhone from the original MacBook Air Codex App connection settings.
• Removed/revoked the iPhone from the MacBook Pro Codex App connection settings.
• Uninstalled and reinstalled ChatGPT on iPhone.
• Signed back into the same ChatGPT account/workspace.
• Completed ChatGPT/OpenAI MFA/passkey/security verification.
• Used “log out all devices”.
• Tried to create a new mobile pairing from the original MacBook Air again.
• Tried to create a new mobile pairing from the migrated MacBook Pro.
• Installed the standalone Codex CLI because the remote-control daemon required it.
• Started the remote-control/app-server daemon.

Observed diagnostics

The desktop app-server remote-control enrollment did not complete. I saw errors like:

remote control server enrollment failed at
https://chatgpt.com/backend-api/wham/remote/control/server/enroll

HTTP 403 Forbidden
body: {"detail":"Multi-factor authentication required"}

After additional auth attempts, I also saw:

HTTP 401 Unauthorized
code: token_invalidated
message: Your authentication token has been invalidated. Please try signing in again.

Expected behavior

After revoking/removing a mobile device from the original Mac, the iPhone should either:

1. remove the stale Codex Desktop connection, or
2. allow the user to delete/reset it manually, or
3. allow a fresh QR pairing with either the original MacBook Air or the migrated MacBook Pro.

A Migration Assistant transfer should not leave two desktop clients thinking they are connected to the same iPhone while the iPhone only shows one undeletable old host identity.

Actual behavior

The stale MacBook Air / old Codex Desktop connection remains visible on iPhone, cannot be removed, cannot connect, and appears to block a fresh pairing to either the original MacBook Air or the migrated MacBook Pro.

Why this may be useful

This may be a migration-specific variant of the stale Remote Control state bug: desktop host identity, server-side environment state, and iOS mobile connection state may not recover cleanly after a Mac-to-Mac Apple Migration Assistant transfer. In this case, the migration appears to have left both Macs with a copied/duplicated local remote-control state, while the mobile app/server side still exposes only the old Air host.

Update: I was able to resolve this on the migrated MacBook Pro.

In my case, this did not look like a hard “only one device can be paired” limit. After resetting the local Codex host identity, the ChatGPT iOS app changed the stale Air entry to MacBook-Pro.local, so the server/mobile side was able to recognize the new Mac.

The actual blocker was the desktop remote-control enrollment. The useful diagnostic was:

remote control server enrollment failed at
https://chatgpt.com/backend-api/wham/remote/control/server/enroll

HTTP 403 Forbidden
body: {"detail":"Multi-factor authentication required"}

What fixed it for me:

1. Reset the copied local Codex installation/device identity on the new Mac.
2. Cleared the old local remote-control pairing/cache state.
3. Updated the standalone app-server/remote-control daemon from 0.135.0 to 0.136.0.
4. Logged back into Codex/ChatGPT on the Mac.
5. Enabled MFA on my OpenAI/ChatGPT account.
6. Restarted remote control:

codex remote-control start --json

After MFA was enabled, the command returned:

{"status":"connected","serverName":"MacBook-Pro.local"}

After that, the iPhone ChatGPT app connected successfully to the existing MacBook-Pro.local entry.

One leftover: the iOS app showed two identical MacBook-Pro.local entries after repeated pairing attempts. The Mac only had one active --remote-control process, so that appears to be duplicate server-side/mobile connection records rather than two local services. I left the working one enabled and can ignore/remove the duplicate from the app UI.

Adding a Linux daemon + ChatGPT mobile stale-pairing datapoint that looks very close to this issue.

Environment:

• Host: Linux x86_64
• Codex CLI / managed app-server: 0.142.5
• Remote-control mode: daemon-managed app-server
• Mobile surface: ChatGPT mobile app Codex remote control

User-visible symptom:

• The mobile app can still see the host/device.
• Tapping the host does not connect.
• The problem started after logging out of the mobile app and logging back in.
• Another PC under the same account also changed from connectable to not connectable around the same time.
• The mobile app does not expose a usable entry point for the manual pairing code generated by the daemon-side pairing RPC.

Current local/server evidence:

codex app-server daemon version
status: running
cliVersion: 0.142.5
appServerVersion: 0.142.5

Persisted local enrollment is enabled and points at the current cloud environment:

server_name: ps
server_id: srv_e_6a47...99b9
environment_id: env_e_6a47...4376
remote_control_enabled: 1

The app-server control RPC reports the daemon as connected for that same environment:

{
  "status": "connected",
  "serverName": "ps",
  "environmentId": "env_e_6a47...4376"
}

But listing controller clients for the current environment returns an empty list:

{
  "data": [],
  "nextCursor": null
}

An older environment ID that the phone may have cached now returns cloud-side 404:

GET /backend-api/wham/remote/control/environments/env_e_6a1a...a9638/clients
HTTP 404 Not Found
{"detail":"Remote environment not found"}

I also started a daemon-side pairing session through the app-server v2 RPC remoteControl/pairing/start with manualCode: true. It returned a valid-looking manualPairingCode and the current environment ID, but the ChatGPT mobile app did not provide a way to enter or claim that code. Polling/listing afterward still showed clients: [].

Local logs also do not show a mobile-origin thread/list or other remote JSON-RPC request arriving at the host after the failed mobile connection attempt. That suggests the request is not reaching the host; the failure boundary is before host-side request processing, likely in mobile/account/cloud association for the stale host/environment.

This is not a 409 case at the moment: the current Linux daemon environment is connected. The broken state is closer to: mobile still displays a stale host record, while the currently connected environment has no authorized controller client and there is no mobile-side forget/re-pair path that can claim the fresh environment.

I was able to resolve this in my case.

The root cause turned out to be authentication rather than the pairing flow itself.

I had not enabled MFA on my ChatGPT/OpenAI account. After enabling multi-factor authentication with an authenticator app, signing in again, and restarting the remote control setup, pairing completed successfully.

If you're seeing errors such as:

• HTTP 403 Forbidden
• {"detail":"Multi-factor authentication required"}
• 401 Unauthorized
• token_invalidated

I recommend enabling MFA (Authenticator app), signing back into Codex/ChatGPT, and trying the pairing process again.

Hopefully this helps someone else running into the same issue.