›_ Codex Issues
Codex Issues / #38128

Remote Control blocks ChatGPT Android enrollment on official unrooted GrapheneOS

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

What version of Codex / ChatGPT is affected?

ChatGPT for Android 1.2026.216 (build 2621629)

Subscription

ChatGPT account with Remote Control available

Host

Codex Remote Control host enrollment succeeds and fresh QR/manual pairing codes are generated. The host receives no client claim when the Android failure occurs.

Summary

Codex Remote Control cannot enroll a controller from ChatGPT Android on GrapheneOS. The Android app rejects the request before it claims or contacts the waiting host.

This reproduces on both:

  • an unrooted Pixel 5 running an official GrapheneOS release, with sandboxed Google Play services and Play Store installed; and
  • a Pixel 8 Pro running GrapheneOS with a user-controlled AVB signing key.

The unrooted official GrapheneOS reproduction rules out root, Magisk, and custom signing as necessary causes.

Steps to reproduce

  1. Install ChatGPT from Google Play on an unrooted Pixel running an official GrapheneOS release.
  2. Install sandboxed Google Play services and Google Play Store.
  3. Sign into the same ChatGPT account used by the Remote Control host.
  4. Open Remote Control in ChatGPT Android.
  5. Scan a fresh QR code or enter a fresh manual pairing code.
  6. Observe:
Pairing failed. Something went wrong while pairing. Try scanning the code again.

The same result occurs with repeated fresh codes.

Android-side evidence

During the failed attempt, ChatGPT Android sends:

POST https://android.chat.openai.com/backend-api/codex/remote/control/client/enroll/start

The response is:

HTTP 403
{"cf_details":"Request is not allowed. Please try again later.","type":"dc"}

The application classifies it as a Cloudflare error.

The failure occurs at the initial controller enrollment request, before Android device-key creation, step-up authentication, pairing-code claim, or communication with the host. The waiting host receives no pairing claim.

The APK contains Play Integrity/device-check integration including the _playintegrity cookie and oai-android-play-integrity-token handling. GrapheneOS's Play Store reports the device as not certified even on the unrooted official installation.

This makes a Play Integrity or device-certification gate the strongest explanation. Please confirm the actual policy because the generic UI message currently hides it.

Why this is not an authentication failure

Both endpoints are already authenticated to the same ChatGPT account:

  • ChatGPT Android works normally.
  • Codex/Desktop works normally.
  • Remote Control host enrollment and pairing-code generation work.
  • The controller enrollment endpoint rejects the phone before the pairing protocol begins.

Google Play certification does not establish account authorization. It also rejects locked, verified and current alternative operating systems while accepting any OS licensed by Google.

Requested changes

  1. Confirm and document whether Android controller enrollment requires a Play Integrity verdict.
  2. Support standard Android hardware key attestation and permit official GrapheneOS verified-boot keys.
  3. Provide an account-bound fallback using explicit host approval plus password/OTP step-up.
  4. Return a specific diagnostic error for device-policy rejection instead of “Pairing failed.”
  5. Ensure the security property is possession of an enrolled non-exportable key, not Google certification of the operating system.

GrapheneOS publishes a signed, maintained verified-boot-key feed and implementation guidance:

https://grapheneos.org/articles/attestation-compatibility-guide

This permits verification of genuine hardware, verified boot, OS patch level, application identity and hardware-backed key possession without weakening the Remote Control security model or requiring Google Play certification.

Related issue

  • #37897 reports the same generic Android failure and absence of host-side activity, but attributes it to the Linux host. The evidence above shows the Android controller is rejected at client/enroll/start, before host type or the pairing code is evaluated.

I can provide sanitized Android telemetry privately if an OpenAI engineer needs the Cloudflare Ray IDs or full event sequence.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 16 days ago

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

  • #37897

Powered by Codex Action

preyevates · 16 days ago

Reviewed #37897. This is related but not a duplicate.

#37897 reports the generic UI symptom against a Linux CLI host and infers that the failure is in Android or the pairing backend. This issue adds the missing root-cause boundary:

  • the Android controller receives HTTP 403 from client/enroll/start;
  • rejection occurs before the pairing code or host is contacted;
  • it reproduces on an unrooted Pixel 5 running an official GrapheneOS release;
  • it specifically requests review of the Play Integrity/device-certification policy and support for GrapheneOS hardware attestation.

Closing this as a duplicate would lose the device-policy reproduction and attestation request. I have cross-linked #38128 from #37897 so maintainers can correlate the shared user-visible symptom.

LIghtJUNction · 13 days ago

Additional reproduction on Linux desktop + Android:

Environment:

  • ChatGPT Android 1.2026.216 (versionCode 2621629) on Android 16, device model PHK110.
  • ChatGPT desktop 26.803.81509-1 on Linux.
  • The desktop Connections setting allows remote control, and the phone and desktop use the same authenticated account.

Reproduction:

  1. Open desktop Settings > Connections > allow remote control and display the phone QR code.
  2. On Android, open Work > Remote, choose that I am logged in on desktop, then try both QR scanning and the manual phone pairing-code flow.
  3. Repeat with fresh QR/code values.

Result:

  • Both methods end in the Android UI: “Pairing failed. Something went wrong while pairing. Please scan the QR code again.”
  • The desktop remains at zero remote connections and receives no visible claim.
  • ChatGPT normal HTTPS access works after removing a controlled direct-route test; there is no TLS interception in the working proxy path.

Could maintainers check the response from the Android client enrollment endpoint for this device/account and whether the failure occurs before device-key creation or host claim, as described in this issue? No pairing codes, subscription URLs, or account tokens are included here.

MicaLovesKPOP · 2 hours ago

I’m independently affected by this exact issue.

Setup:

  • Codex running on Windows
  • ChatGPT Android app
  • Android device is not Google Play certified, and cannot be made Play certified
  • ChatGPT itself otherwise works normally

Behavior:

  1. Codex displays the Remote pairing QR code.
  2. My phone recognizes the QR code immediately.
  3. The ChatGPT app instantly shows:

“Pairing failed. Something went wrong while pairing. Try scanning the code again.”

  1. The Windows PC shows no indication that any pairing attempt ever reached it.

So this does not appear to be a QR decoding, camera, local network, firewall, or Windows-side connectivity problem. The failure happens on the Android side before the Codex host is involved.

If the Android Remote enrollment flow currently requires Google Play certification / Play Integrity, please consider supporting a fallback for non-certified Android installations. An authenticated OpenAI-account flow with explicit desktop approval, 2FA, or another device-verification mechanism would be preferable to making Google certification a hard dependency.

At minimum, the app should return a specific error explaining that device certification or attestation caused the rejection. The current generic “Pairing failed” message makes the problem look like a broken QR code or networking issue and leads users down the wrong troubleshooting path.

I’d be happy to provide further device/app details if useful.