Codex App: infinite sign-in loop — app never receives a chatgpt.com session cookie, so backend-api calls 401 ("Missing valid access token or actor biscuit")

What version of the Codex App are you using (From “About Codex” dialog)?

26.818.31338 (also reproduced on 26.818.22352); Codex Framework 151.0.7922.170

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.6.0 arm64 arm (macOS 26.6.1, build 25G76, Apple M2 Max)

What issue are you seeing?

The app launches signed-in and renders the full UI (sidebar, pinned chats, projects, account). Opening ANY thread immediately returns to the "Sign in to ChatGPT" screen. Signing in again succeeds in the browser, and the loop repeats. Started ~2026-08-18. The Codex CLI is completely unaffected and works normally on the same machine and account.

Root cause (evidence below): the app never obtains a chatgpt.com web session cookie.

Server response on the app's UI calls:

{"detail":"Missing valid access token or actor biscuit"}

App log then discards its own token:

desktop_fetch_auth_401  hadToken=true  target="GET https://chatgpt.com/backend-api/accounts/:param/settings"
sa_server_request_failed  status=401  errorMessage={"detail":"Unauthorized"}
app_server_connection.auth_status_result  hasToken=false  nullReason=auth_token_missing  tokenExpiryState=missing
-> all subsequent calls: hadToken=false  skipRetryReason=no_token_attached -> 401

Failing routes are all chatgpt.com web backend-api, never the Codex API:
/accounts/{id}/settings, /accounts/optimized/check, /wham/onboarding/context, /wham/usage, /wham/tasks/list, /aip/first-party/eligibility, /amphora/notifications, /beacons/home, /sentinel/heartbeat

Cookie-jar evidence (decisive). Immediately after a fully successful OAuth sign-in:

Chrome's jar — 31 chatgpt.com cookies including a valid session:

__Secure-next-auth.session-token   expires 2026-11-19
__Secure-oai-is                    expires 2026-09-20
cf_clearance, _puid, __obref, ...

The app's jar (~/Library/Application Support/Codex/Default/Cookies) — 5 cookies, no session at all:

__cf_bm, __cflb, __oailb, _cfuvid, _devicecheck

There is no __Secure-next-auth.session-token in the app's jar under any condition. The OAuth completes in the external browser and the resulting web session is deposited in the browser's jar, never the app's.

Token evidence. auth.json after a fresh sign-in is complete and valid, but scoped to the Codex API rather than chatgpt.com:

aud:       ["https://api.openai.com/v1"]
scp:       ["openid","profile","email","offline_access","api.connectors.read","api.connectors.invoke"]
client_id: app_EMoamEEZ73f0CkXaXp7hrann

That same auth.json authenticates the CLI successfully (codex exec returns normally) seconds after the app is rejected. So the credential is valid — it simply carries no authority for chatgpt.com/backend-api/*, and the flow never provisions the session that endpoint requires.

What steps can reproduce the bug?

1. Launch the Codex app on macOS 26.6.1. It renders signed-in.
2. Click any thread in the sidebar.
3. App returns to the "Sign in to ChatGPT" screen.
4. Click "Continue to sign in" -> browser opens -> consent page -> Continue.
   The localhost callback on 127.0.0.1:1455 is consumed and a fresh valid auth.json is written.
5. App shows the signed-in UI again. Open any thread -> back to step 3. Loops indefinitely.

Inspect the app's cookie jar at any point:

sqlite3 "$HOME/Library/Application Support/Codex/Default/Cookies" \
  "select host_key,name from cookies where host_key like '%chatgpt%';"

Result is always the same 5 non-session cookies; __Secure-next-auth.session-token never appears.

Things tried that do NOT fix it (all verified, all leave the jar without a session cookie)

1. Completing the in-app sign-in end to end (callback consumed, fresh token written).
2. The chatgpt.com/codex/open-app?source=login&app_brand=chatgpt handoff page ("You're signed in and may close this tab") — clicked its "Open ChatGPT" button.
3. Deep-linking that same handoff URL into the app's own webview via open -b com.openai.codex "<url>" (the app declares http/https handlers).
4. A completely fresh Chromium profile for the app.
5. Updating from 26.818.22352 to the latest 26.818.31338.
6. Deleting the keychain item "Codex Safe Storage" and clearing the cookie jar so the app regenerates its encryption key (rules out "app cannot decrypt its own jar"; note a fresh profile does NOT cover this, since it reuses the same keychain key).
7. Removing ~/.codex/auth.json entirely and letting the app run its own sign-in from scratch — it re-mints the identical client_id / aud: https://api.openai.com/v1 / same scopes, and still gets no session cookie. This confirms the token above is the app's own OAuth registration, not borrowed CLI state.
8. "Sign in another way" only offers an OpenAI API key, which is not applicable to a ChatGPT-plan user.

Ruled out (tested, not assumed)

• Account/subscription: Pro, active, single org, owner. CLI works on the same credential.
• Bundle integrity: codesign -v valid and notarized, satisfies its Designated Requirement.
• Keychain: item present and regenerable (see 6).
• Network interference: /etc/hosts clean, no VPN or proxy configured, Malwarebytes engine active but with zero block verdicts in RTProtectionDaemon.log (only unrelated June/July file-read warnings).
• Pending device/security verification: no email from OpenAI in the preceding 10 days.
• Stale LaunchServices registrations claiming codex: — moot, since the callback is an HTTP listener on 127.0.0.1:1455, and open codex:// resolves to the correct app.
• An oversized local thread (a 2.1 GB rollout existed and was archived); small healthy threads fail identically.

What is the expected behavior?

Completing the sign-in flow should leave the app able to open threads and stay signed in.

Concretely, one of the following needs to hold:

• the external-browser sign-in deposits the chatgpt.com session into the app's cookie jar (not only the default browser's), or
• the app performs sign-in inside its own browser context so the session lands there natively, or
• the token the app is issued (aud: https://api.openai.com/v1) is accepted by the chatgpt.com/backend-api/* endpoints the app's UI depends on.

Today none of the three holds, so the app is unusable on this machine while the CLI works fine.

Additional information

An OpenAI Support case is already open for this: Case 13489309 (2026-08-20). The steps suggested there were reinstalling, disabling VPN/proxy/secure DNS/antivirus web protection, and confirming the original auth method — the network-related ones have since been verified as non-factors (no VPN or proxy configured, /etc/hosts clean, Malwarebytes shows zero block verdicts), and reinstall-grade state resets are covered in the list above.

Two useful diagnostics for anyone triaging this:

# app's cookie jar — should contain a session cookie after sign-in, but never does
sqlite3 "$HOME/Library/Application Support/Codex/Default/Cookies" \
  "select host_key,name from cookies where host_key like '%chatgpt%';"

# launch with logging to see the 401 -> token-discard sequence
/Applications/ChatGPT.app/Contents/MacOS/ChatGPT --enable-logging=stderr --v=1 2>&1 \
  | grep -E "desktop_fetch_auth_401|auth_status_result|actor biscuit"

Unrelated but worth flagging for others: unregistering Sparkle's Updater.app from LaunchServices will silently stall the app's own updater at "Extracting update…". Re-registering it with lsregister -f on ~/Library/Caches/com.openai.codex/org.sparkle-project.Sparkle/Launcher/*/Updater.app restores updating.

All identifiers (account id, user id, org id, email, device serial) have been redacted from this report.

Start with the macOS app sign-in flow around the 127.0.0.1:1455 callback, then inspect auth.json, the app cookie database at ~/Library/Application Support/Codex/Default/Cookies, and the logged 401 sequence. Done means completing sign-in provisions a usable chatgpt.com session for the app, allowing threads to open without returning to the sign-in screen.