Codex CLI login forces SMS phone OTP step-up on a security-key-only (Advanced Account Security) account; browser login honors AAS
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
- An account with Advanced Account Security + FIDO2 security keys and no phone factor.
codex login(stock, macOS) → local callback server onhttp://localhost:1455→ genuine OpenAI OAuth athttps://auth.openai.com/oauth/authorize(PKCES256, scopeopenid profile email offline_access api.connectors.read api.connectors.invoke).- Complete primary auth with the hardware security key.
- Flow redirects to
auth.openai.com/phone-otp/select-channeldemanding 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.
21 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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).
Same here. It is horrible to be honest and i'm not able to access anything.
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.
same issue here, always got OTP since OpenAI Advanced Account Security enabled
https://auth.openai.com/api/accounts/phone-otp/send
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 loginstill redirects to thephone-otp/select-channelSMS/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.
@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
same EXACT issue. Does openai know about it yet? I am currently contacting support.
I'm experiencing the same exact issue, which is very annoying. Please let us know when the fix will be available.
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:
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.
Update: still reproduces on 2026-06-18. Isolated CODEX_HOME
codex login --device-authredirects toauth.openai.com/add-phonebefore completing Codex OAuth. Support case 10188773 is open/escalated.Same here, cannot login to my account
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...
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.
+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.
Same isssue here
same issue here
I have the same issue with AAS and old phone verification
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
AAS failure is still present, no accounts have been recovered.
Linking https://github.com/openai/codex/issues/25837 and https://github.com/openai/codex/issues/25670