Codex CLI login forces SMS phone OTP step-up on a security-key-only (Advanced Account Security) account; browser login honors AAS

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

What happens

On a fresh codex login (stock CLI, no wrappers or automation), the CLI opens the standard OpenAI browser OAuth flow. Primary authentication with my FIDO2/CTAP2 hardware security key succeeds, and the flow then redirects to https://auth.openai.com/phone-otp/select-channel and presents a "Verify your phone number" SMS/WhatsApp one-time-code dialog. That step-up cannot be satisfied with my enrolled hardware keys, so sign-in is blocked.

Crucially, normal browser sign-in to ChatGPT and to platform.openai.com on the same account — with the same security keys — resolves correctly and never prompts for a phone. Only the codex login CLI OAuth path forces the SMS step-up. This looks like a cross-surface authenticator-policy gap: the web sign-in enforces the account's policy; the Codex CLI path falls back to an SMS channel the policy is documented to disable.

Account configuration

  • OpenAI Advanced Account Security enabled
  • Two FIDO2/CTAP2 hardware security keys enrolled
  • No phone-based authentication factor configured
  • Per OpenAI's docs, Advanced Account Security disables SMS sign-in codes and SMS account recovery (help.openai.com/en/articles/20001221), relying on passkeys/security keys.

Expected behavior

On an Advanced Account Security / security-key-only account with no phone factor, step-up verification should use an enrolled factor (security key / passkey) — not an SMS/WhatsApp OTP that AAS is documented to disable.

Actual behavior

auth.openai.com/phone-otp/select-channel offers only SMS/WhatsApp OTP to a phone number that is not a currently-configured factor on the account. With AAS + security keys and no phone factor, there is no way to complete the step-up, so Codex sign-in is unusable — while browser sign-in on the same account works.

Steps to reproduce

  1. An account with Advanced Account Security + FIDO2 security keys and no phone factor.
  2. codex login (stock, macOS) → local callback server on http://localhost:1455 → genuine OpenAI OAuth at https://auth.openai.com/oauth/authorize (PKCE S256, scope openid profile email offline_access api.connectors.read api.connectors.invoke).
  3. Complete primary auth with the hardware security key.
  4. Flow redirects to auth.openai.com/phone-otp/select-channel demanding SMS/WhatsApp OTP → blocked.

Environment

  • Codex CLI (stock), macOS, June 2026.
  • Reproduced with raw codex login — no wrappers, proxies, or automation.

Impact

Users who deliberately hardened their account with Advanced Account Security + security keys (and intentionally have no phone factor) can be fully locked out of Codex by an SMS step-up they cannot complete, even though their browser sign-in on the same account succeeds.

Possibly related

#20161, #20320, #21189, and discussion #20868 — but those don't isolate the Advanced Account Security cross-surface angle (web honors AAS; the CLI path forces SMS).

Note

Account-specific details and the affected phone number have been reported to OpenAI privately and are intentionally omitted here.

View original on GitHub ↗

21 Comments

github-actions[bot] contributor · 1 month ago

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

  • #25670
  • #24990

Powered by Codex Action

Jesssullivan · 1 month ago

To be clear, AFAICT this is a serverside and an exploitable bug, not a codex CLI issue. Haven't been able to get through this and figured given codex is the touchpoint for me, perhaps others have encountered this and can get the attention the issue needs.

(I am a human, for what its worth).

fahdfady · 1 month ago

Same here. It is horrible to be honest and i'm not able to access anything.

LaiZhou · 1 month ago

I am a ChatGPT Plus subscriber.

My ChatGPT account works normally.

I previously used Codex successfully.

After signing in on another device, my Codex authentication was invalidated and I was forced to re-authenticate.

Now every Codex login redirects to the phone verification page.

The phone number previously associated with my account is no longer accessible because it has been retired by the carrier.

I cannot complete the verification process and therefore cannot access Codex.

Could you please help recover access to my Codex account or update the verification method?

Thank you.

barayuda · 1 month ago

same issue here, always got OTP since OpenAI Advanced Account Security enabled

https://auth.openai.com/api/accounts/phone-otp/send

{
  "error": {
    "message": "You've made too many phone verification requests. Please try again later or contact us through our help center at help.openai.com.",
    "type": "invalid_request_error",
    "param": null,
    "code": "rate_limit_exceeded"
  }
}
afram123 · 1 month ago

Reproduced on Windows + Codex CLI, confirming this exact cross-surface gap.

I enrolled in Advanced Account Security (two passkeys/security keys + authenticator app, SMS MFA off). Browser sign-in to ChatGPT honors the passkeys with no phone prompt — but codex login still redirects to the phone-otp/select-channel SMS/WhatsApp step-up, targeting an old number I no longer have access to. So AAS does not suppress the SMS channel for the Codex OAuth flow, and enrolling in it does not fix the lockout — contrary to what the "disable SMS sign-in codes" description would suggest.

As an EU (Sweden) user I'm also pursuing this as a GDPR Article 16 (rectification) / Article 17 (erasure) request, since the account holds an inaccurate phone number that current policy won't let me correct except by deleting the account.

Related: #25749, #25800.

Jesssullivan · 1 month ago

@afram123 Thanks for adding this reproduction, this is exactly our observed bug. 🙏 GDPR Articles 16 / 17 req appears to be exactly the appropriate course of action.

-Jess

peeky-co · 1 month ago

same EXACT issue. Does openai know about it yet? I am currently contacting support.

zhuylanz · 1 month ago

I'm experiencing the same exact issue, which is very annoying. Please let us know when the fix will be available.

zhulijin1991 · 1 month ago

Adding another data point for the same AAS / Codex OAuth behavior.

Since around 2026-06-16 evening Asia/Shanghai, a paid Pro/Business-enabled account started failing Codex re-auth while ChatGPT web still works. Codex CLI / Desktop OAuth device login redirects to phone verification / add-phone. Advanced Account Security / MFA is enabled, but the Codex flow still asks for phone/SMS-style verification instead of using the configured stronger auth method.

The existing Codex refresh token was invalidated, so re-auth is required; re-auth then blocks on the phone verification step.

Environment:

  • macOS, Apple Silicon
  • codex-cli 0.140.0 installed via npm global @openai/codex@0.140.0
  • Codex Desktop bundled CLI present: 0.140.0-alpha.19

This looks specific to Codex OAuth re-auth and not to general ChatGPT web login. A Help Center support conversation has already been escalated to a support specialist.

zhulijin1991 · 1 month ago

Update: still reproduces on 2026-06-18. Isolated CODEX_HOME codex login --device-auth redirects to auth.openai.com/add-phone before completing Codex OAuth. Support case 10188773 is open/escalated.

arita37 · 1 month ago

Same here, cannot login to my account

jwics7 · 25 days ago

I am having the same issue. I am a paying Max subscriber but can't login to Codex the last month because it wants me to verify with an old phone number and no way to change it. This is unacceptable. What are they doing over there in auth/sec? This means they're not inspecting their auth stack closely...

afram123 · 16 days ago

Recurred 2026-07-04 — still not fixed.

This hit me again today, identical to the 2–4 June episode. Codex CLI login still forces the SMS/WhatsApp phone-OTP step-up (auth.openai.com/phone-otp/select-channel) on my Advanced Account Security account, even though I have an authenticator app plus two passkeys/security keys enrolled. Browser/web login honours AAS and signs in normally — only the CLI forces the phone step. The number on file is disconnected, and there is still no way to change or remove it without deleting the entire account and waiting 30 days.

OpenAI Support told me on 4 June (Case 09535487) that "the issue that was preventing some users from receiving verification codes has now been resolved." That was only a temporary code-delivery patch — the actual defect here (the CLI ignoring AAS/passkeys and forcing OTP to an unchangeable dead number) was never addressed, which is exactly why it's back a month later.

Today I've reopened both OpenAI support cases and renewed a formal GDPR Article 16/17 rectification request over the inaccurate number. Posting here so the recurrence is on the record for others hitting the same wall.

lakely0 · 10 days ago

+1, same deadlock here. Turkish Plus , old number deactivated by carrier. ChatGPT web + AAS + passkey works fine, but Codex CLI/Desktop OAuth forces auth.openai.com/phone-otp/select-channel→ SMS to the dead number → blocked. Support case escalated twice, both replies "create new account" which is nonsense for a paying user (lose TR pricing / chats / GPTs).

This is clearly the CLI-AAS gap @Jesssullivan isolated — web honors AAS, CLI doesn't. Recurred Jul 4 per @afram123, root cause still unaddressed. Would really appreciate a server-side fix (or at least a manual step-up reset path for affected Plus/Pro accounts) instead of "delete and re-sign-up" being the only answer.

kl3inIT · 10 days ago

Same isssue here

SongZihan · 10 days ago

same issue here

limboSeeker · 10 days ago

I have the same issue with AAS and old phone verification

hustcer · 10 days ago

Why has this severe UX-breaking issue been left unresolved for so long? Ignoring user complaints while continuing to make paying customers bear the cost of your own errors — is that really your approach? @codex team

Jesssullivan · 5 days ago

AAS failure is still present, no accounts have been recovered.