Remote Control blocks ChatGPT Android enrollment on official unrooted GrapheneOS

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.

Begin at the Android POST to /backend-api/codex/remote/control/client/enroll/start and compare it with the host enrollment flow described in the report; related issue #37897 provides context. Done means confirming whether Play Integrity or device certification is required, documenting the supported policy, and exposing a specific diagnostic result instead of the generic pairing failure.