{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreieta3g7antykyxbmqhpxwualdbtog6iz4zczfcfnvihz4m3wcha7a",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mnecgchjs4h2"
  },
  "path": "/t/codex-client-auth-forces-whatsapp-code-to-a-dead-number-but-chatgpt-codex-web-log-in-fine-case-09491223/1382372#post_8",
  "publishedAt": "2026-06-03T04:02:25.000Z",
  "site": "https://community.openai.com",
  "tags": [
    "@owallesun"
  ],
  "textContent": "This matches my case exactly, and @owallesun’s theory fits perfectly. On my account, ChatGPT web and Codex web log in fine, and my MFA (Authenticator) works — the **only** failure is Codex client authorization (Mac app + CLI), which forces a code to my **original registered number** (+44 …, permanently deactivated by the carrier) instead of honoring my configured MFA method.\n\nI’ve already updated to the latest Codex app + CLI per the macOS signing-rotation email; no change. So if recent client auth is falling back to the original registered phone number rather than the MFA method on file, that would explain why passkeys/Authenticator are ignored and only the dead SMS/WhatsApp number is accepted. Could the engineering team check whether Codex client auth is incorrectly verifying the original registered number instead of the user’s configured MFA method? Case 09491223.",
  "title": "Codex client auth forces WhatsApp code to a dead number — but ChatGPT/Codex web log in fine (Case 09491223)"
}