Codex Remote Android enrollment fails on Huawei Mate40 Pro while Mate20 Pro succeeds on same host/account/network

Summary

Codex Remote enrollment consistently fails on a Huawei Mate40 Pro, while a Huawei Mate20 Pro successfully pairs to the same Windows Codex host using the same ChatGPT account and network/VPN environment.

The failure appears to occur after the pairing credential is accepted but before the Mate40 becomes an authorized Remote device on the Windows host.

I would like OpenAI to confirm from server-side enrollment/authentication logs why the Mate40 enrollment is rejected, and whether Codex Remote device enrollment has any Play Protect / Google Play Integrity requirement that is not currently documented.

Environment

Windows host

• Windows 10 Pro, 64-bit
• Codex desktop package during final A/B: 26.825.6671.0
• Remote Control enabled
• Same host, account, and network used for both phones

Working control device

• Huawei Mate20 Pro
• Android 10
• Google Play Protect: certified
• Play Integrity checker: device recognition shows MEETS_STRONG_INTEGRITY
• Codex Remote pairing succeeds
• Windows Codex shows the phone in Devices that can control this computer

Failing device

• Huawei Mate40 Pro
• HarmonyOS 4
• Google Mobile Services installed after purchase rather than native certified GMS
• Google Play Protect: device not certified
• Play Integrity checker: device recognition shows only MEETS_BASIC_INTEGRITY
• ChatGPT Android login works
• Codex Remote pairing consistently fails
• The Mate40 never appears in the Windows authorized-device list

Controlled A/B results

The following variables were held constant:

• Same Windows PC
• Same Codex desktop installation
• Same ChatGPT account
• Same network/VPN exit
• Same Remote Control configuration

Result:

• Mate20 Pro -> pairing succeeds
• Mate40 Pro -> pairing fails

Windows-side observations

For the failing Mate40 attempt, Codex successfully starts the pairing operation:

method=remoteControl/pairing/start ... errorCode=null

Subsequent calls such as:

method=remoteControl/client/list ... errorCode=null

also complete without an explicit error.

The successful Mate20 A/B run shows the same high-level Windows-side behavior: remoteControl/pairing/start completes with errorCode=null.

We also observed nextConnectionCount=0 in both the failed Mate40 run and the successful Mate20 run, so that field does not appear to distinguish pairing success in this build.

No clear pairing-related HTTP 401/403/409 or explicit server rejection reason was exposed in the Windows desktop log.

Android-side observations

On the Mate40, ChatGPT:

• launches normally
• requests network access
• interacts with Google Play / Google Play services
• binds to Google Play services
• reaches com.google.android.gms.chimera.container.moduleinstall.ModuleInstallService.START
• opens the camera successfully when QR pairing is used

The successful Mate20 flow shows a very similar scanner/GMS/ModuleInstall/camera sequence.

Therefore, camera startup, basic QR scanning infrastructure, and GMS ModuleInstall do not appear to explain the A/B difference.

Manual pairing test

To eliminate QR scanning / ML Kit / camera / deep-link handling as the primary cause, the Mate40 was also tested using the manual pairing code rather than QR scanning.

Result:

• pairing credential is accepted and the pairing flow starts
• the app waits/spins
• pairing ultimately fails
• the Mate40 still does not appear in the Windows authorized-device list

This strongly localizes the failure to a stage after receipt of the pairing credential and before completion of authorized-device enrollment.

Important integrity-related A/B difference

The strongest remaining device-level difference is:

• Mate20: Play Protect certified; integrity checker shows Strong; enrollment succeeds
• Mate40: Play Protect uncertified; integrity checker shows Basic only; enrollment fails

However, I have not found OpenAI documentation stating that Codex Remote requires MEETS_DEVICE_INTEGRITY or MEETS_STRONG_INTEGRITY. Therefore I am treating this as correlation, not proof of causation.

What has been substantially ruled out

• Windows host unable to support Remote
• ChatGPT account problem
• basic VPN/node problem
• Wi-Fi vs mobile-data path
• camera not opening
• QR-only failure (manual code fails too)
• missing GMS ModuleInstall flow
• remoteControl/pairing/start failing on Windows
• nextConnectionCount=0 as a reliable failure indicator

Requested investigation

Could the Codex/ChatGPT team please inspect server-side Remote enrollment/authentication telemetry for this failure class and clarify:

1. At which exact enrollment stage is the Mate40 rejected or failing?
2. Does Codex Remote Android enrollment directly use Google Play Integrity or Play Protect certification?
3. If Play Integrity is used, which verdict is required (BASIC, DEVICE, STRONG, or another policy)?
4. Is HarmonyOS 4 with post-installed GMS unsupported for Codex Remote even when the ChatGPT Android app can sign in and otherwise function normally?
5. Is there a known Android compatibility bug where pairing credentials are accepted but device enrollment never completes?
6. Is there an additional diagnostic identifier/log that users can capture to correlate a failed mobile enrollment with server-side logs?

I can provide sanitized Windows Codex logs and Android logcat captures for both the successful Mate20 control run and failed Mate40 run if needed. I have intentionally not included account identifiers, pairing credentials, tokens, or other sensitive data in this public report.

Start by comparing the supplied Windows Codex logs and Android logcat captures for the successful Mate20 and failing Mate40 runs, focusing on remoteControl/pairing/start and remoteControl/client/list. Correlate those events with server-side enrollment telemetry to identify the rejection stage. Done means documenting the required integrity or HarmonyOS conditions, or providing a diagnostic identifier that distinguishes the failure.