Codex Desktop macOS: opening any session causes auth token loss and returns to Sign In after configuring Remote Connection

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

Version 26.818.21641

What subscription do you have?

Plus

What platform is your computer?

macOS 26.6.1
Apple Silicon
64-bit

What issue are you seeing?

Since Aug 19, 2026, opening a Codex session causes Codex Desktop to immediately return to the ChatGPT Sign In screen.

Authentication initially succeeds and the session itself appears to load successfully. Logs show:

thread/read → errorCode=null
thread/resume → errorCode=null
maybe_resume_success

Immediately afterward, Desktop authentication fails:

desktop_fetch_auth_401 hadToken=true

authMethod=chatgpt
hasToken=false
nullReason=auth_token_missing
refreshToken=true
tokenExpiryState=missing

authenticatedAccountPresent=false
failureType=account_info_token_unavailable

Subsequent requests then show:

desktop_fetch_auth_401
hadToken=false
skipRetryReason=no_token_attached

HTTP 401 Unauthorized

One request explicitly reports:

Unauthorized - Access token is missing

Signing in again succeeds, but opening a session immediately reproduces the same loop.

This appears to match the authentication regression reported in #39162, with closely related symptoms in #39581 and #39491.

What steps can reproduce the bug?

Launch Codex Desktop on macOS.
Sign into ChatGPT successfully.
Open an existing Codex session.
The thread begins loading/resuming successfully.
Desktop receives an authenticated 401 (hadToken=true).
Auth state changes to auth_token_missing / hasToken=false.
Subsequent requests are made with hadToken=false and return 401.
Desktop redirects to the ChatGPT Sign In screen.
Sign in again and open a session.
The same failure repeats.

I have reproduced this across multiple sessions.

What is the expected behavior?

Opening or resuming a Codex session should preserve the authenticated ChatGPT account state and load the session normally.

A failed authenticated request/token refresh should not cause Desktop to discard the available authentication state and subsequently issue requests without an access token.

Additional information

The issue first appeared immediately after I configured a Remote Connection on Aug 19.

I initially suspected Remote Control, but the problem persists after revoking all connections and disabling Remote Control entirely. I therefore cannot establish that Remote Connection caused the issue; it may only have coincided with or exposed the underlying authentication regression.

Troubleshooting completed:

Reinstalled Codex/ChatGPT Desktop — no change.
Signed out and performed fresh authentication — no change.
Tested multiple existing sessions — same behavior.
Revoked all Remote Connections — no change.
Disabled Remote Control entirely — no change.
Removed ~/.codex/auth.json and reauthenticated — no change.
Moved the entire ~/.codex directory aside and allowed Codex to generate completely fresh state — no change.
Removed the macOS Keychain Codex Safe Storage entry and performed fresh authentication — no change.
Fully restarted the application/processes — no change.
codex doctor reports databases healthy, config loaded, auth configured, WebSocket connected, and provider endpoints reachable.

The issue therefore reproduces with fresh Codex state and freshly initialized secure storage.

There is also a stale local workspace reference that generates an unrelated ENOENT/fs/readFile warning. However, thread/read, thread/resume, and maybe_resume_success complete before authentication collapses, so this does not appear to cause the Sign In loop.

The auth sequence appears particularly close to #39162:

authenticated
→ thread resume succeeds
→ hadToken=true
→ HTTP 401
→ auth_token_missing
→ hasToken=false
→ subsequent hadToken=false requests
→ Sign In

Related reports:

#39162 — macOS, near-identical auth sequence
#39581 — similar token/auth-state collapse
#39491 — similar behavior on Windows

Sanitized Desktop log containing the complete reproduction: codex-desktop-2026-08-20.log

Start by reproducing the session-opening flow on macOS and compare the sanitized Desktop log with issues #39162, #39581, and #39491. Trace the transition from an authenticated 401 through auth_token_missing and hasToken=false; done means opening or resuming a session preserves authentication instead of redirecting to Sign In.