[macOS] ChatGPT Desktop repeatedly returns to “Continue to sign in” when OAuth login is completed in Safari, but works immediately with Chrome

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

ChatGPT 26.818.31338 Build 6892

What subscription do you have?

ChatGPT Pro Lite

What platform is your computer?

macOS, Apple Silicon

What issue are you seeing?

The new unified ChatGPT desktop app repeatedly returns to the “Continue to sign in” screen when authentication is completed using Safari as the default browser.

Authentication appears to complete successfully in Safari, but the desktop app does not retain a usable authenticated state and eventually returns to the sign-in screen.

Changing the default browser to Google Chrome and completing the same authentication flow immediately resolves the issue.

After successfully authenticating through Chrome, the desktop app works normally.

I narrowed down the issue through a step-by-step troubleshooting process in ChatGPT using GPT-5.6 Sol with Medium reasoning effort, progressively ruling out local app state, network conditions, background processes, and authentication state before isolating the browser-dependent behavior.

What steps can reproduce the bug?

1. Set Safari as the default browser on macOS.
2. Launch the ChatGPT desktop app.
3. Select “Continue to sign in.”
4. Complete ChatGPT authentication in Safari.
5. Return to the desktop app.
6. The app initially appears authenticated, but returns to the “Continue to sign in” state.
7. Change the macOS default browser to Google Chrome.
8. Repeat the authentication process.
9. Authentication succeeds and the desktop app remains signed in.

What is the expected behavior?

Expected behavior

Authentication completed through Safari should result in the same persistent authenticated desktop session as authentication completed through Chrome.

Actual Behavior

Safari-based authentication results in a recurring sign-in loop, while Chrome-based authentication works immediately.

Additional information

Troubleshooting performed

Before identifying the Safari/Chrome difference, I performed a full local authentication reset, including:

• Removed desktop application state under:
  • ~/Library/Application Support/com.openai.codex
  • ~/Library/Caches/com.openai.codex
  • ~/Library/HTTPStorages/com.openai.codex
  • ~/Library/Preferences/com.openai.codex.plist
• Reset .codex-global-state.json
• Removed relevant local authentication state and reauthenticated
• Reinstalled the desktop application
• Tested on multiple unrelated Wi-Fi networks
• Confirmed that ChatGPT works normally in the browser
• Confirmed that no orphaned Codex background processes remain after quitting the desktop app

None of these steps resolved the issue.

The issue was resolved immediately by performing the OAuth login through Chrome instead of Safari.

Safari configuration

Safari's warning for HTTP websites is disabled, so this does not appear to be caused by Safari's HTTP warning setting.

Additional observations

This may be related to Safari/WebKit handling of the OAuth redirect or localhost callback used by the desktop application.

A possibly related issue is:

• #33535 — “Login via Safari”

However, that issue appears to describe a visible localhost error during authentication, whereas in this case authentication appears to complete and the desktop application subsequently returns to the sign-in state.

Given that switching only the browser used for the OAuth flow changes the outcome, this looks like a browser-dependent issue in the desktop authentication flow rather than a network, account, or persistent local-state problem.

Potential duplicates

I reviewed #40029 and #39162. The surface symptom is similar, but I don't think this is confirmed as a duplicate yet. Those reports reproduce when opening an existing conversation and appear tied to the /accounts/:param/settings 401 regression. In my case, the decisive variable is the browser used for OAuth: authentication through Safari consistently leads to the loop, while repeating the same flow through Chrome immediately resolves it on the same app build, account, and machine. I'll keep this open unless maintainers confirm the underlying cause is the same.

Start by reproducing the OAuth flow from the desktop app’s “Continue to sign in” entry point with Safari and Chrome on macOS. Trace the browser redirect or localhost callback and compare the resulting authenticated state; done means Safari produces the same persistent signed-in session as Chrome.