›_ Codex Issues
Codex Issues / #22775

Remote control authorization fails in Codex 26.513.20950 (2816): "Failed to authorize remote control"

Open 💬 3 comments Opened May 15, 2026 by flyyangX

Describe the bug

Attempting to enable remote control from Codex on macOS fails with an error.

Codex version: 26.513.20950 (2816)
Platform: macOS (device is online and Codex app is running)

Steps to reproduce

  1. Open Codex on macOS
  2. Go to Settings → Connections → Control other devices from this Mac
  3. Click Authorize on chatgpt.com / follow the prompt

Expected behavior

Authorization succeeds and remote control can be used.

Actual behavior

A toast/error banner shows:

Failed to authorize remote control

Additional context

  • Confirmed I am logged in with the same ChatGPT account/workspace.
  • Others have reported the same behavior on GitHub issues (same Codex version).
  • Screenshot attached (error banner) if needed.

View original on GitHub ↗

3 Comments

maharris77 · 3 months ago

See https://github.com/openai/codex/issues/22696

Snailflyer · 3 months ago

For this class of authorization failure, the UI needs to surface which identity check failed.

"Failed to authorize remote control" could mean at least four different things: mobile account mismatch, desktop account mismatch, workspace/account-user-id mismatch, or enrollment endpoint failure. Those require different recovery steps, and users cannot infer them from the toast.

A useful error would include a redacted reason category and next action, for example account_mismatch, workspace_mismatch, enrollment_rejected, or relay_unreachable. That would also make duplicate reports easier to merge, because the visible symptom is identical while the backend failure can differ.

phishsticks · 14 days ago

This is happening to me too.
MacOS ChatGPT Version 26.810.41047.

Edit:
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.