Codex mobile Remote Control stale host cannot be removed and QR pairing fails

Yeah same here, it's kind of annoying as it did load the chat titles but never made it into a thread. Then trying to re-auth has me also stuck with the machine I cant delete from the iOS app. There is no exposed way to delete a connection on the app.

@ardjo-s I have a workaround that calls the server side endpoint to list / delete these connections: https://gist.github.com/sirmalloc/fefef0b65729d9644794a3c67d1a28b9

me too

Update after testing the workaround from @sirmalloc.

First, thank you @sirmalloc for putting that Gist together and trying to help. I tested it against my account. It did help clean up stale server-side environments: the backend endpoint now returns backend_count=0.

Unfortunately, the original issue still reproduces after that cleanup.

Current state:

• Codex CLI: codex-cli 0.130.0
• Codex macOS app: 26.513.20950 build 2816
• Backend /codex/remote/control/environments?limit=100: backend_count=0
• Local SQLite remote_control_enrollments: 0
• iOS still shows the stale Codex Desktop host / pairing state
• QR pairing still gets stuck on iOS at “Waiting for desktop”
• macOS Codex QR screen does not progress

The suspicious part is that after deleting the backend environments and clearing local enrollment rows, the desktop app still rewrites stale local remote-control keys into ~/.codex/.codex-global-state.json:

{
  "codex-mobile-has-connected-device": true,
  "electron-local-remote-control-environment-id": "env_e_6a0643abd32483299424094ab98270cd",
  "electron-local-remote-control-installation-id": "dd270cae-4a76-4757-9f2f-70c44278c368"
}

So the workaround seems to solve only the server-side stale environment list. The remaining bug looks like the desktop/iOS pairing flow can stay stuck with stale client-side state even when the backend environment list is empty.

A product-side “forget/reset remote control host” path, or a stronger cleanup of the desktop/iOS pairing state, may be needed.

Additional update after testing the QR flow again, following the documented path:

1. macOS Codex App > Settings
2. Connections
3. Control this Mac
4. Generate the QR code
5. On iPhone: Codex > Connections > Add connection > scan the QR code

Observed behavior:

• On macOS, the QR screen is generated and stays stuck on Approve on your device.
• On iPhone, after scanning the QR code, the app gets stuck waiting/searching for the desktop.
• The iOS Connections screen loops between a loading/skeleton connection card and then an empty state with only Add connection; no desktop host is found.
• The previous stale Host-003.lan entry no longer appears, so the backend cleanup did remove the stale host entry. The remaining failure is that a fresh desktop pairing/discovery never completes.

Current diagnostics from the Mac after reproducing this:

• codex-cli 0.130.0
• remote_control feature flag is true
• Backend GET /backend-api/codex/remote/control/environments?limit=100: HTTP 200, count 0
• Local SQLite remote_control_enrollments: 0
• ~/.codex/.codex-global-state.json still contains/recreates the local remote-control state keys (electron-local-remote-control-installation-id, electron-local-remote-control-environment-id, codex-mobile-has-connected-device) after relaunching the app

This looks like two separate things now:

1. @sirmalloc's workaround successfully clears the stale server-side host list.
2. The current macOS/iOS QR pairing path still does not complete even with the backend list empty and local enrollments empty.

I avoided posting the raw QR-code screenshot directly because it contains a pairing code, but the visible macOS state is the modal stuck at Approve on your device, while iOS stays in the search/no-host-found loop described above.

| iPhone: searching | iPhone: empty state |
|---|---|
| <img src="https://github.com/user-attachments/assets/a2ba235c-27e2-473c-89a2-03a4ab14a31c" width="320"> | <img src="https://github.com/user-attachments/assets/1a6be308-9089-4f88-a032-a1400408280c" width="320"> |

I'm having this issue too, has anyone found a workaround that gets things working again?

EDIT: Ok it turns out if you remove the app and it's data from your iPhone, then reinstall, then log out and log in again it all works.

I've had success after logging out of the iPhone app and logging back in. It starts the pairing flow over again after revoking the device via the codex desktop app.

Additional update after the clean-reset attempt and retesting the QR pairing flow.

First, thanks @sirmalloc for the logout/login suggestion and earlier workaround. I tried the iPhone-side reset path as well: removed/reinstalled the ChatGPT iOS app, logged back in, and started the pairing flow again from Add connection. Unfortunately the QR pairing still hangs.

Current observed behavior remains:

| Desktop | iPhone |
|---|---|
| Codex macOS shows the QR modal and stays on Approve on your device. | iPhone stays on Waiting for desktop / searching after scanning the QR. |

Local state after running a clean reset while Codex was closed:

Codex.app: 26.513.20950, build 2816
codex-cli: 0.130.0
macOS: 26.4.1, build 25E253

Current verification output after reopening Codex:

$ codex features list | rg 'remote_control|remote_connections'
remote_control                          under development  false

$ jq -r 'to_entries[] | select(.key|test("electron-local-remote-control|codex-mobile|remote-project-connection")) | "\(.key)=\(.value)"' ~/.codex/.codex-global-state.json
remote-project-connection-backfill-completed=true
electron-local-remote-control-installation-id=dd270cae-4a76-4757-9f2f-70c44278c368

$ sqlite3 ~/.codex/state_5.sqlite 'select count(*) from remote_control_enrollments;'
0

Backend environments also appear empty from the authenticated backend API check:

GET /backend-api/codex/remote/control/environments?limit=100
count: 0

One suspicious detail: after restoring remote_control = true in ~/.codex/config.toml while Codex is closed, the CLI can report remote_control as true. After launching the macOS GUI again, the app appears to rewrite ~/.codex/config.toml: remote_control = true disappears, while remote_connections = true remains. At the same time, electron-local-remote-control-installation-id reappears in global state even though local enrollments and backend environments are both empty.

So this now looks less like an iOS-only cache issue and more like a desktop state reconciliation/config rewrite issue after the sequence:

1. iPhone was previously paired successfully.
2. User disconnected/revoked access from mobile/desktop.
3. Subsequent QR pairing attempts hang indefinitely.
4. Clean local reset leaves enrollments empty, but desktop relaunch recreates stale remote-control state and removes the remote_control feature flag from config.

I have not deleted ~/.codex/auth.json, changed macOS Sharing/Remote Login, or changed the hostname. The symptom is unchanged after the clean reset.

@ardjo-s Dont just login after reinstall, it still fails that way. You have to log out while logged in. Any other way keeps something in the keychain around that breaks the flow, even after deleting and reinstalling and logging in on a fresh install.

Arf tried everything - this release was not for me. I'll try next Thursday!

@codex-maintainers @codex Still no official fix for this bug?

New update from today's retest.

The failure mode changed again. iOS now gets past the initial mobile setup screen far enough to show the auth page (Authorize Codex on this device), but the setup still fails with:

Setup failed
Couldn't finish secure setup. Try again.

After that, the iOS Connections screen shows a stale desktop entry:

Codex Desktop
Host-003.lan
Codex on this environment is out of date. Update to 0.129.0-alpha.6 or newer.
Current version: 0.128.0

Local state on the Mac at the same time:

macOS: 26.5, build 25F71
Codex.app: 26.513.31313, build 2867
/Applications/Codex.app embedded codex: codex-cli 0.131.0-alpha.9
Homebrew codex: codex-cli 0.130.0
remote_control feature flag before local fix: false
remote_control feature flag after `codex features enable remote_control`: true
remote_control_enrollments: 0

The backend remote-control environment list explained the stale iOS UI. Before cleanup it contained one stale environment:

count: 1
display_name / host_name: Host-003.lan
client_type: CODEX_DESKTOP_APP
online: false
app_server_version: 0.128.0
installation_id: null

I deleted that environment with the backend DELETE endpoint. The first delete returned HTTP 204 but the same stale host reappeared once with a new environment id. A second bounded delete pass removed it, and a follow-up check after a short wait now shows:

GET /backend-api/codex/remote/control/environments?limit=100
count: 0
items: []

So the new state is:

1. The stale iOS Host-003.lan / 0.128.0 card came from the server-side environments endpoint, not from the current installed Codex.app on disk.
2. The installed app bundle is already above the requested version (0.131.0-alpha.9 embedded app-server/CLI).
3. The desktop config had again lost remote_control = true; I re-enabled it locally and verified the effective flag is now true.
4. Local enrollments are still empty.

I did not fully quit/relaunch Codex.app from inside this active Codex Desktop session, because that would risk killing the running report session. The next useful verification is a full Codex.app relaunch and a fresh mobile pairing attempt after the backend list is empty and remote_control is enabled.

Follow-up from the same retest: deleting the stale backend environment was not sufficient.

After the stale Host-003.lan / 0.128.0 environment was removed, a fresh mobile setup attempt still fails on iOS with the generic:

Setup failed
Couldn't finish secure setup. Try again.

I then found a more precise desktop-side failure in the local app-server logs. The desktop app-server attempts to create a new remote control enrollment, but the enrollment endpoint rejects it:

creating new remote control enrollment:
websocket_url=wss://chatgpt.com/backend-api/wham/remote/control/server
enroll_url=https://chatgpt.com/backend-api/wham/remote/control/server/enroll

failed to connect to app-server remote control websocket:
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"}

This repeats after the app-server's auth recovery attempts (reload and refresh_token). The UI-facing status event remains:

{"method":"remoteControl/status/changed","params":{"status":"errored","installationId":"dd270cae-4a76-4757-9f2f-70c44278c368","environmentId":null}}

Current local/backend state after the retry:

Codex.app: 26.513.31313, build 2867
embedded codex: codex-cli 0.131.0-alpha.9
login status: Logged in using ChatGPT
remote_control feature as reported by the active app config: false
remote_control_enrollments in ~/.codex/state_5.sqlite: 0
backend environments list: count 0, items []

I also tried the embedded daemon tooling as a workaround:

codex app-server daemon enable-remote-control
=> remoteControlEnabled: true

codex app-server daemon start
=> appServerVersion: 0.131.0-alpha.9

That starts a managed app-server with --enable remote_control, but enrollment still fails with the same HTTP 403 Forbidden / Multi-factor authentication required, so no fresh environment is advertised and the backend list remains empty.

One extra note: while trying to restart only the background app-server, the Codex Desktop UI showed a crash page with (code=null, signal=SIGTERM). That was caused by terminating the child app-server process during the workaround attempt, not by the original iOS pairing action. The relevant pairing failure is the enrollment 403 above.

So the current blocker no longer appears to be only the stale server-side environment. The current fresh-enrollment path is failing because the desktop app-server receives an MFA-required response from /backend-api/wham/remote/control/server/enroll, while the mobile UI only surfaces a generic secure-setup failure.

Follow-up after checking the current local state and the official Codex remote connection docs.

Current state on 2026-05-20 18:38 CEST:

• Managed app-server daemon is running: cliVersion=0.131.0-alpha.9, appServerVersion=0.131.0-alpha.9.
• Codex is logged in using ChatGPT.
• Local remote_control_enrollments count is still 0.
• The daemon keeps trying to enroll at https://chatgpt.com/backend-api/wham/remote/control/server/enroll and gets:
• HTTP 403 Forbidden
• body: {"detail":"Multi-factor authentication required"}
• recent request id: 0e571e18-5bbc-42e6-9cb8-33fe9df7515d

This now matches the official Codex remote connection docs, which say mobile setup must finish any required multi-factor authentication, SSO, or passkey steps before retrying, and that setup still failing after that can require confirming workspace Remote Control access is enabled: https://developers.openai.com/codex/remote-connections#authentication-blocks-setup

So the stale 0.128.0 environment is gone and the local daemon is current/running, but fresh enrollment is blocked by an account/workspace MFA requirement that the desktop daemon's auth recovery does not satisfy automatically.

Additional state after the user confirmed their MFA provider behavior:

• User uses Dashlane and confirms that the MFA/passkey confirmation does happen during the mobile setup/auth flow.
• Immediately after that, a fresh desktop daemon retry still fails enrollment:
• local time: 2026-05-20 18:48 CEST
• endpoint: https://chatgpt.com/backend-api/wham/remote/control/server/enroll
• result: HTTP 403 Forbidden
• body: {"detail":"Multi-factor authentication required"}
• request id: 41bd7a57-2e8a-41f2-956a-2fdef7a46215
• Managed app-server daemon remains running on 0.131.0-alpha.9.
• Local remote_control_enrollments remains 0.
• Backend remote-control environments list remains empty: count=0.

This suggests the visible Dashlane/MFA confirmation is not being reflected in the auth state used by the desktop app-server daemon enrollment request, or the enrollment path is checking a different account/workspace auth requirement than the one satisfied in the mobile/browser flow.

Final local re-auth attempt before full reinstall/reset:

• Enabled device-code authorization in ChatGPT security settings, then reran codex login --device-auth.
• First re-auth appeared successful, but the daemon/backend then returned 401 token_invalidated and reported the refresh token was revoked.
• Per that backend guidance, ran a clean codex logout, then codex login --device-auth again.
• Login succeeded and the managed app-server daemon was restarted cleanly.
• Fresh enrollment still fails with HTTP 403 Forbidden and body {"detail":"Multi-factor authentication required"}.
• Latest request id observed after clean logout/login: dc7e859f-d6a0-469d-8f76-cf86fbe3a847 at 2026-05-20 19:09 CEST.
• Local remote_control_enrollments remains 0.
• Backend remote-control environments list remains count=0.

At this point the user is moving to a full Codex/CodexBar uninstall/reset to remove local app state before reinstalling.

The later repros here suggest two different stale-state problems may be getting mixed:

1. stale mobile-side/backend host rows that survive local reset/reinstall;
2. fresh enrollment attempts failing before a new local remote_control_enrollments row is created.

Those need different fixes. Deleting the old backend environment can address the first without proving the second enrollment path is healthy.

For the fresh setup failure, the most useful discriminator may be the first durable state transition that does not happen:

• does the desktop daemon receive the QR/mobile pairing attempt at all;
• does it create or update any local enrollment row;
• does the backend return a stable environment id before token_invalidated / 401;
• after re-auth, does the daemon use the new token or keep retrying with a revoked refresh token.

If local enrollment count remains 0 after a fresh authenticated attempt, this looks upstream of normal mobile connection state; if a row is created and then mobile still shows stale hosts, it is more likely a backend/mobile host-list reconciliation issue.

Do you still see remote_control_enrollments = 0 after the clean re-auth, or does a new row appear and then fail later?

Closing this from my side after a full reset/retest, but I want to leave the most complete state I have because the fix path is still a bit ambiguous.

cc @codex-maintainers @codex for awareness.

What changed

After the previous failing state, I did a very broad local reset/reinstall of Codex/CodexBar and then completed the ChatGPT account security/MFA flow again.

The two things that changed were:

1. I removed/recreated the local Codex desktop state.
2. I completed the ChatGPT security/MFA flow using SMS notification + Dashlane/passkey behavior.

I am not 100% sure which of those actually unblocked the root cause, or whether both were required. My current guess is that both mattered: the local reset removed stale desktop identity/state, while the ChatGPT security flow made the backend accept the fresh remote-control enrollment.

Local reset performed

From shell history, the reset targeted at least:

/Applications/Codex.app
/Applications/CodexBar.app
~/.codex
~/.codexbar
~/.cache/codex-runtimes
~/.local/bin/codex
/opt/homebrew/bin/codex
/opt/homebrew/Caskroom/codex*
/opt/homebrew/Caskroom/codexbar*
~/Library/Application Support/Codex
~/Library/Application Support/CodexBar
~/Library/Application Support/com.steipete.codexbar
~/Library/Application Support/com.openai.chat/codex-*
~/Library/Caches/com.openai.codex
~/Library/Caches/CodexBar
~/Library/Caches/com.steipete.codexbar
~/Library/Preferences/com.openai.codex.plist
~/Library/Preferences/com.steipete.codexbar.plist
~/Library/Logs/com.openai.codex
~/Library/Logs/CodexBar
~/Library/HTTPStorages/com.openai.codex*
~/Library/HTTPStorages/com.steipete.codexbar*
~/Library/WebKit/com.steipete.codexbar
~/Library/Containers/com.steipete.codexbar.widget
~/Library/Group Containers/Y5PE65HELJ.com.steipete.codexbar
~/Library/Group Containers/group.com.steipete.codexbar

Previous failing state

Before the reset/MFA retest, the issue had evolved into two separate failure modes:

1. Stale backend/mobile host state:

iOS showed stale host: Host-003.lan
Reported app-server version: 0.128.0
Backend environments count before cleanup: 1
Backend environments count after cleanup: 0
Local remote_control_enrollments: 0

1. Fresh enrollment blocked by MFA:

endpoint: https://chatgpt.com/backend-api/wham/remote/control/server/enroll
result: HTTP 403 Forbidden
body: {"detail":"Multi-factor authentication required"}
local remote_control_enrollments: 0

So deleting the stale backend environment fixed the stale host row, but did not by itself make fresh pairing work. The fresh enrollment path was still blocked before any local enrollment row was created.

Current working-ish state after reset + MFA/security flow

Current machine/app state:

macOS: 26.5, build 25F71
Codex.app: 26.513.31313, build 2867
codex-cli: 0.131.0-alpha.9
login status: Logged in using ChatGPT

The newly recreated local Codex state shows:

~/.codex birth time: 2026-05-20 19:53:17 CEST
auth.json birth time: 2026-05-20 19:53:27 CEST
remote_control_enrollments: 1
enrollment updated_at: 2026-05-20 17:56:34 UTC / 19:56:34 CEST

The enrollment row now exists:

environment_id: env_e_6a0df5d1d71c832996b8fa1ac00eaa9f
server_name: Host-003.lan
client: Codex Desktop

And ~/.codex/.codex-global-state.json now contains fresh local remote-control state:

electron-local-remote-control-installation-id=8662606c-1e53-4ebb-a170-36b8d8789e6b
electron-local-remote-control-environment-id=env_e_6a0df5d1d71c832996b8fa1ac00eaa9f
codex-mobile-has-connected-device=true

One odd detail: codex features list currently still reports:

remote_control    under development    false

but the local enrollment row exists now, which is the important difference from the previous failing state.

My read

There seem to be two distinct bugs or at least two distinct recovery requirements here:

1. Stale server/mobile host rows can survive local reinstall/reset and make iOS show an old Host-003.lan / 0.128.0 environment that is not the currently installed desktop app.
2. Fresh desktop enrollment can fail before creating any local remote_control_enrollments row if the backend returns Multi-factor authentication required. In my case, the visible mobile/browser auth flow did not seem to satisfy the auth state used by the desktop daemon until I went through the ChatGPT security/MFA flow with SMS + Dashlane.

The main product issue, in my opinion, is that the user-facing mobile setup only showed a generic secure setup failure, while the useful desktop-side error was the backend 403 Multi-factor authentication required. Also, a full ~/.codex reset probably should not be necessary to recover from this kind of state.

I am no longer blocked after the full reset + MFA/security retest, so closing from the reporter side. I am leaving the details here in case this helps distinguish stale environment cleanup from the separate fresh-enrollment/MFA failure path.

Thanks for leaving the final state here. This is useful because it keeps the failure split into two gates instead of collapsing everything into "mobile pairing is broken".

My read of your final result is:

1. stale local desktop identity/state can keep the setup path poisoned even after backend environment cleanup;
2. the fresh enrollment path can still be blocked by account/security/MFA state until the ChatGPT-side security flow is fully satisfied;
3. once both are reset, the system can create a new working enrollment again.

For maintainers, the product fix probably should not require users to do a full app/cache/keychain-style reset. A safer flow would be an explicit "forget this desktop / regenerate host identity" action plus a setup error that distinguishes stale host identity from MFA/security enrollment rejection.

That would turn this from a destructive reset workaround into a diagnosable recovery path.

If you knew how many tokens I used before having to nuke Codex on my Mac…
@tibo-openai, thank you. The final reset was clearly what was needed to close this issue.

Yes, that cost is exactly why the recovery path needs to become a first-class product flow instead of tribal cleanup knowledge.

A full local nuke works as proof that stale desktop identity/state was part of the failure, but it is too destructive to be the expected fix. The actionable version would be something like:

• show the current desktop host identity and enrollment state;
• let the user revoke/forget/regenerate that host identity explicitly;
• distinguish "host identity stale" from "MFA/security enrollment blocked" in the setup error;
• avoid requiring users to discover every Codex/CodexBar cache, plist, WebKit, group container, and CLI path by trial and error.

Leaving this closed makes sense if your setup is unblocked, but the diagnostic trail here is still useful for turning the reset workaround into a supported recovery flow.

@Snailflyer, please stop posting AI-generated replies to our issue tracker. You're generating a lot of noise for maintainers.

Understood. Sorry for the noise. I will stop posting these replies in this issue tracker.

I am hitting what appears to be the same stale-host recovery problem, with Windows Desktop + ChatGPT iOS.

The important difference in my case is that the host had paired successfully before. The broken state started after the phone/device entry was accidentally deleted from the Codex Desktop side. After that:

• Codex Desktop -> Connections shows no devices that can control this computer.
• ChatGPT iOS still shows the old Codex Desktop host record as disconnected/offline.
• Generating and scanning a fresh QR code does not create a clean new pairing.
• iOS appears to keep/reuse the stale old host record.
• Trying to complete setup fails with Setup failed / Couldn't finish secure setup. Try again (Chinese UI: 设置失败 / 无法完成安全设置。请重试。).

This looks like a state mismatch between desktop-side paired-device deletion and mobile/account-side host retention. A user-visible "Forget/remove this computer" action on iOS, plus a fresh QR path that can replace stale enrollment state, would likely fix this recovery case.

I opened a focused Windows + iOS variant of this stale-host issue here: #26535

It reproduces after deleting the paired phone from the desktop-side Connections UI: desktop has no controlling devices, but iOS keeps the old offline host and fresh QR setup fails with Setup failed / Couldn't finish secure setup.