[Android][Remote] "Authorize this phone" loops after the desktop switches ChatGPT accounts: stale cross-account environment, two pending enrollments per attempt #48555

Summary

After a desktop app was signed into account B and then back into account A on the same machine, pairing an Android phone with account A loops forever. After scanning the QR code, tapping Authorize this phone and completing the browser sign-in, the app returns to the same "Allow this phone to access ChatGPT on your computer?" screen with no error, and the desktop never receives a claim. This matches #39698 (trigger) and #36268 (symptom); this issue collects all findings in one place.

Environment

• Desktop: ChatGPT Desktop 26.924.22138 on Linux (Ubuntu 26.04), bundled Codex 0.158.0-alpha.2.1
• Phone: ChatGPT for Android 1.2026.265 on a Google-certified stock Android 17 phone (Play Integrity is not a factor; ChatGPT itself works normally)
• Personal accounts; the host's remote-control connection stays connected throughout

Trigger

The desktop app was signed into account B for a while, then signed back into account A (same machine, same Codex home). Phone pairing for account A then looped at "Authorize this phone" (browser sign-in completes, app returns to the same screen, host never sees a claim).

What the backend showed

The desktop's single remote-control installation was registered as an environment under both accounts. Account B still had an offline environment for the same installation ID, left over from when the desktop was signed into B. Account A had its own online environment for that installation. Every failed attempt also left pending_enrollment clients on account A (two per attempt) that never completed.

What was cleared (the loop is not confirmed fixed)

1. With account B's credentials: DELETE /backend-api/wham/remote/control/environments/{env_id} for the stale environment whose installation_id matched the desktop now used by account A (HTTP 204). GET .../wham/remote/control/environments lists them with installation_id and online.
2. Removed account B's rows from the desktop's local remote_control_enrollments table (state_5.sqlite in the Codex home), after a backup.
3. Removed the stale pending_enrollment clients (DELETE .../wham/remote/control/clients/{client_id}).

Ruled out

The number of linked phones (all were removed), DNS filtering and TLS interception, and the host's remote-control connection (connected throughout).

Request to OpenAI

When a desktop installation signs into a different account, the backend (or the app) should retire that installation's environment on the previous account, or the phone authorization should report an explicit account/installation conflict instead of silently looping. Related: #36268, #23112.

Additional technical detail

• Two enrollments per failed attempt, one per success: every failed "Authorize this phone" attempt creates two pending_enrollment clients about one second apart. Every successful pairing on the same phone, on both accounts, before and after this regression, created exactly one client. This suggests the Android app starts device enrollment twice and then completes (or fails to complete) the wrong one.
• Silent failure after the security re-check: the Android app (1.2026.265) includes handling for a rejected step-up token during Remote enrollment ("Remote-control enrollment requires interactive password and MFA step-up", a step-up-token-rejected exception, and "device-key challenge does not match local enrollment"). The loop looks like one of these failing without any message to the user.
• App-link verification: on the affected phone, Android reports the ChatGPT app's tt.chatgpt.com link domain as legacy_failure. All other ChatGPT and OpenAI domains are verified. The browser redirect still reaches the app's WebRedirectActivity and then WebAuthenticationActivity, so the redirect is delivered. Another reporter on [Android] "Authorize this phone" loops forever after ChatGPT app reinstall — web auth completes, app never consumes the approval, host receives zero pairing claims #36268 saw the same state.
• Host side: the desktop's remoteControl/pairing/start succeeds, and while the QR code is shown the desktop polls remoteControl/client/list about once a second. No enrolled client ever appears, and no pairing claim reaches the host.
• Second process on the same installation: a headless codex remote-control process sharing the same Codex home was also registered. It stood by with HTTP 409 ("Remote app server already online") while the desktop held the connection. Pausing it during an attempt did not change the result.