›_ Codex Issues
Codex Issues / #39959

iOS Remote Control pairing fails at secure setup on two different hosts: revoked iPhone cannot re-enroll, never-revoked iPad also fails (claimed=false)

Open 💬 3 comments Opened Aug 21, 2026 by wangxiaobao0726-netizen
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Related issues: #37925, #22700, #23339, #23112, #28119

Versions

  • Host 1: Mac mini (Apple Silicon), ChatGPT desktop 26.814.41407 (Build 6720, checked 2026-08-19)
  • Host 2: second ChatGPT desktop host on a laptop (works fine as a desktop controller of Host 1 over the internet)
  • iPhone 16 Plus: latest iOS, ChatGPT iOS 1.2026.223
  • iPad Pro 11" (M5): iPadOS 26.4.2, ChatGPT 1.2026.202 at time of failure
  • Same personal account & workspace on all devices; TOTP (authenticator app) MFA enabled

Cross-device matrix
| Controller | Host | Result |
| --- | --- | --- |
| Laptop (desktop app) | Mac mini | ✅ works, cross-internet |
| iPhone | Mac mini | ❌ secure setup error / "pairing failed, scan again" |
| iPhone | Host 2 (laptop) | ❌ same failure |
| iPad (never revoked) | Mac mini | ❌ "secure setup could not be completed" |

Key evidence

  • Host-side remoteControl/pairing/start succeeds, errorCode=null

(request c7f876af-4163-4c8d-8650-1a819afdfbf9, 2026-08-19 21:46:09 UTC+7).

  • During the pairing window, 19 consecutive client/list calls succeed;

3 local refreshes show nextConnectionCount=0; the pairing session stays
claimed=false; no mobile client is ever created. Re-scanning the same QR
does not create a second pairing session.

  • The iPhone enrollment was revoked on 2026-08-03 (client/revoke OK,

errorCode=null). Since then, re-pairing never completes on either host —
matches the pattern in #37925 and #22700.

  • The iPad was never revoked; its client record

(cli_3573f8827ea64b8c9ecf790a039ef7f7) still exists and refreshes
lastSeenAt, yet secure setup always fails — a stale enrollment that cannot
re-establish, similar to #23339 / #28119 (refresh rejected for stale or
revoked clients).

  • Local registration cleanup was already tried on 2026-08-04 (full backup,

app fully quit, records removed from local storage): on relaunch the backend
restored the same environment / server / installation IDs and the stale iPad
client, so the blocking state is at least partly server-side.

  • Full reinstall of the iPhone app plus a phone restart did not help —

consistent with #22700 (revoked connections survive reinstall).

Local read-only diagnostics (2026-08-21)

  • ~/.codex/.codex-global-state.json on the Mac mini host was inspected

read-only after a verified backup:

  • electron-local-remote-control-environment-id =

env_e_6a0839f0f1748327854244b433e52bd3 and
electron-local-remote-control-installation-id =
3ad2f159-a692-47aa-9c16-81bbaede6a34, both matching the live environment.

  • electron-remote-control-client-enrollments is absent, and a recursive

key scan found no other key containing pairing or enrollment. The only
other Remote-Control-specific state is
electron-remote-control-config-migration-completed=true.

  • So the local stale-enrollment workarounds from #23112 / #28119 do not apply

here: there is nothing local to clear on the host, and host-side registration
state appears to have been migrated out of the JSON global state on current
builds (registrations were previously observed in the app's local SQLite
store on 2026-08-04).

  • A backend read-only check (clients / environments / mfa_requirement) was

not performed: no authenticated session was safely reusable and we did
not extract tokens or re-authenticate. No claim is made about backend state —
that is exactly what we need OpenAI to check.

Environment IDs (non-credentials)

  • environment env_e_6a0839f0f1748327854244b433e52bd3
  • server srv_e_6a0839f0f1848327858568dcc614468c
  • installation 3ad2f159-a692-47aa-9c16-81bbaede6a34

Asks

  1. Check whether the mobile secure-claim for request c7f876af-… ever reached

the backend; if it did, what rejected it (auth policy / MFA factor /
workspace policy / credential validation / stale revoked-device binding).

  1. Check account-side mobile controller enrollments for stale / revoked /

duplicate state.

  1. Provide (or perform server-side) a reset of the *mobile controller

enrollment only*, without resetting the account, chats, Codex tasks, or the
two host environments.

OpenAI support case 12650539 contains full sanitized logs; it has had no
substantive engineering response since 2026-08-05.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 6 days ago

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

  • #39856

Powered by Codex Action

wangxiaobao0726-netizen · 6 days ago

Follow-up: additional read-only diagnostics (2026-08-21) — host local DB + device-side observations

Local SQLite inspection (copy-only, read-only; no state was modified). The host's local app database contains a remote_control_enrollments table (fields: websocket_url, account_id, app_server_client_name, server_id, environment_id, server_name, updated_at, remote_control_enabled) with exactly two live rows:

| app_server_client_name | server_id / environment_id | updated_at (UTC+7) | remote_control_enabled |
| --- | --- | --- | --- |
| Codex Desktop | srv_e_6a0839f0f1848327858568dcc614468c / env_e_6a0839f0f1748327854244b433e52bd3 | 2026-08-19 19:02:12 | true |
| codex_remote_pairing_diagnostic | same server / same environment | 2026-08-05 09:33:49 | null |

The second row was created within ~1 second of the support-requested repro's pairing/start on 2026-08-05 (09:33:50 +07) and still persists today, sharing the same server_id/environment_id as the live host enrollment, with remote_control_enabled=null. Earlier, on 2026-08-04, a diagnostic connection had received HTTP 409 "Remote app server already online".

Question for the team: can a stale duplicate app-server enrollment under the same server identity interfere with completing new mobile secure-claims, while leaving an already-established desktop controller session unaffected?

Note on scope: this table stores host-side app-server enrollments only — it has no mobile client IDs, device types, or revoked/stale flags. The iPad client ID (cli_3573f8827ea64b8c9ecf790a039ef7f7) does not appear in any live TEXT/BLOB field of the DB. Since the host is not expected to store a mobile client list locally, this is not evidence in either direction about backend state.

Device-side observations (same day). Same account on both devices, opposite visible states, identical functional failure:

  • iPhone (revoked 2026-08-03, since fully reinstalled): the Remote connection list is completely empty; fresh pairing still fails at secure setup.
  • iPad (never revoked): the Mac mini host is still listed, but every connection attempt fails with "secure setup could not be completed".

This pattern is consistent with a server-side mobile-controller enrollment block (one device blocked from re-enrolling after revocation, the other unable to re-establish an existing enrollment) rather than visible local residue on either device. No local state was modified during any of these checks.

wangxiaobao0726-netizen · 6 days ago

Re: duplicate check (#39856) — reviewed; related but not a duplicate. Keeping this issue open because the failure stage differs:

  • In #39856, QR pairing succeeds (the mobile client is created and appears in the host's authorized-device list) and the failure occurs afterward, at session establishment/attach — predominantly Android, with a regression window around 2026-08-19, and at least one A/B report there shows iPadOS connecting fine to an affected host.
  • Here, the mobile secure-claim itself never completes: the pairing session stays claimed=false, no mobile client is ever created (19× client/list OK, nextConnectionCount=0), both iOS devices fail, and onset predates that regression window (it began before the 2026-08-03 revocation).

They do look like siblings on the same backend path, though: stale server-side registration evidence appears in both threads — HTTP 409 "Remote app server already online" reported in #39856, and the persistent codex_remote_pairing_diagnostic app-server enrollment with remote_control_enabled=null sharing the live host's server_id/environment_id, documented above in this issue.

Also noteworthy for triage: a commenter in #39856 performed exactly the local host-state reset sometimes suggested for these cases (clearing remote_control_enrollments in the app's SQLite store, rotating installation_id, removing the electron local-remote-control keys) and it did not resolve their mobile failure either — consistent with the blocking state being server-side.

Asks 1–3 in the issue body stand: please check the secure-claim telemetry for request c7f876af-… and this account's mobile controller enrollment state.