›_ Codex Issues
Codex Issues / #34466

Remote Control enrollment fails with OSStatus -25300 on pre-T2 Intel Mac / macOS Monterey

Open 💬 1 comment Opened Jul 21, 2026 by productsjjk-beep

Summary

Remote Control enrollment fails on a 2015 Intel MacBook Pro running macOS Monterey because the desktop app cannot generate its asymmetric device key.

Environment

  • Mac model: MacBookPro11,4 (Intel, 2015 generation; no Secure Enclave/T2)
  • macOS: 12.7.6 (21H1320)
  • ChatGPT/Codex desktop app: 26.715.52143
  • App build: 5591
  • FileVault: Off
  • System Integrity Protection: Enabled
  • Gatekeeper: Enabled

Steps to reproduce

  1. Sign in to the ChatGPT/Codex desktop app.
  2. Open Settings > Connections.
  3. Enable or authorize Remote Control.
  4. Attempt to add/pair a Remote Control connection.

Actual behavior

Enrollment reaches the server challenge successfully, then fails locally while generating the device key:

remote_control_authorize_failed
The operation couldn’t be completed.
(OSStatus error -25300 - failed to generate asymmetric keypair)

The UI can subsequently show a half-created/stale host entry such as:

Remote control is enabled on Jeffs-MacBook-Pro.local but the connection is errored.

Related status reads may then report:

Connection for host ID remote-control:<redacted> not found

Expected behavior

On Macs without Secure Enclave/T2 hardware, Remote Control should successfully use the app's OS-protected non-extractable software-key fallback, or clearly report that the platform is unsupported.

Troubleshooting already performed

  • Confirmed the user login keychain exists and is the default keychain.
  • Unlocked the login keychain.
  • Successfully created and deleted a Secure Note, confirming that the keychain accepts new items.
  • Signed out and back in.
  • Fully quit and restarted the app.
  • Restarted macOS.
  • Repeated enrollment; the same OSStatus -25300 error occurs.
  • macOS firewall and File Sharing are not involved; the failure occurs after the enrollment challenge and before the relay connection is established.

Additional observation

The packaged native module contains strings indicating both a Secure Enclave path and an os-protected-nonextractable fallback. On this pre-T2 Mac, both appear to leave enrollment failing with OSStatus -25300. This may be a compatibility issue in the fallback path on macOS Monterey.

View original on GitHub ↗

1 Comment

phishsticks · 13 days ago

independently reproduced and patched this on an Intel Mac without T2/Secure Enclave.

Environment: MacBookPro14,1, macOS 13.7.8, ChatGPT/Codex 26.810.41047.

The software P-256 fallback in remote-control-device-key.node fails with OSStatus -25293 when kSecAttrAccessControl is used. The same key generation works without access control, even with kSecAttrIsExtractable = false.

I built a compatible replacement module that:

leaves the Secure Enclave path unchanged
omits kSecAttrAccessControl for the software fallback
keeps the key permanent and non-extractable
stores the public key separately for later retrieval

After installing it into an ad-hoc-signed app copy, Remote Control authorization succeeded and the Intel Mac paired successfully with a Linux Codex client.

So the issue appears to be the access-controlled software-key fallback, not P-256 or non-extractability itself.