Codex Windows desktop app deep link / OAuth callback bug #25368

Activity

1. Roins-hub

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on May 31, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   authIssues related to authentication and accountsIssues related to authentication and accounts

   on May 31, 2026
3. github-actions commented on May 31, 2026

   

   github-actionsbot

   on May 31, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • Codex Desktop Windows: connector OAuth "Open in Codex" opens Electron error instead of completing callback #25157
   • Windows Codex app deep link / OAuth callback fails: "Unable to find Electron app" #25188
   • GitHub OAuth callback fails with "Unable to find Electron app" on Windows #25203
   • Windows 10 Store Version: codex://new causes "Cannot find module ...\new" and breaks Chrome/Computer Use OAuth callback #25297
   • Windows Codex app: permission notification click/minimized state launches Electron error #25284

   Powered by Codex Action
4. Licantrop0 commented on May 31, 2026

   

   Licantrop0

   on May 31, 2026

   Last edited by Licantrop0

   More actions

   Same build here (OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0). I think I've got the root cause pinned, plus two theories I can kill.

   What actually triggers it

   For me it's the ChatGPT connector OAuth flow (hooking up a Microsoft/Outlook mail connector). The chain is: Microsoft login → https://chatgpt.com/connector_platform_oauth_redirect → codex://oauth_callback?... back into the app. That last hop is what blows up.

   The upstream authorize URL is login.microsoftonline.com/common/oauth2/v2.0/authorize, and the interesting (non-secret) bits are:

   redirect_uri = https://chatgpt.com/connector_platform_oauth_redirect
   scope        = openid email offline_access Mail.Read MailboxSettings.Read Mail.Read.Shared User.Read
   state        = codex_scheme__oauth_s_<redacted>
   

   That codex_scheme__ prefix on state is the tell: once Microsoft auth finishes, it hands back through a codex:// deep link. Same thing the Figma (#25188), Supabase (#25368), and connector (#25157 / #25257) reports are all hitting.

   The actual bug: the URL lands in argv[1] and gets treated as an app path

   I grabbed the full command line of the process protocol activation spawns vs a normal launch (Get-CimInstance Win32_Process -Filter "Name='Codex.exe'").

   Normal launch (shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App):

   "C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app\Codex.exe"
   

   (no positional args)

   Protocol activation (codex://oauth_callback?code=...):

   "C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app\Codex.exe" codex://oauth_callback/?code=...
   

   So the deep link shows up as the first positional arg, and the bootstrap treats argv[1] as the app to load. It path.resolves the URL against the app dir, which produces:

   ...\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app\codex:\oauth_callback\?code=...
   

   I pulled the exact dialog text via UI Automation (not the truncated version in the tiny dialog):

   Error launching app
   Unable to find Electron app at
     C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app\codex:\oauth_callback\?code=...
   Cannot find module
     'C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app\codex:\oauth_callback\?code=...'
   

   The fix is for the app to pull the codex:// URL out of argv before app resolution and route it through the single-instance handler, instead of resolving it as a path.

   This kills the "space in Program Files" theory (#25238)

   The dialog truncates to C:\Program ... because the box is tiny. The real resolved path is the whole URL bolted onto the app dir (...\app\codex:\oauth_callback\?code=...). Nothing got cut at the space. The whole codex://... string becomes one relative path segment.

   Warm start fails too (app already running)

   1. Launched Codex normally: healthy window, ~8 helper procs.
   2. Fired codex://oauth_callback?code=... while it was up.
   3. A brand new Codex.exe spawned (titled "Error") instead of the URL going to the running instance.

   The crash is in app/module resolution, which runs before the single-instance / open-url handler. So the live instance never sees the URL.

   Re-registering and registry surgery do nothing (I tried)

   codex:// already routes to the right exe. Confirmed the activated process is ...\app\Codex.exe via CIM ExecutablePath. I also found a stale HKCU\Software\Classes\codex key (had URL Protocol, no shell\open\command), removed it, and re-registered:

   Add-AppxPackage -DisableDevelopmentMode -ForceApplicationShutdown -Register AppxManifest.xml
   

   Exit 0, Status=Ok, identical error afterward. The manifest declares <uap:Protocol Name="codex" /> correctly and activation hits the right exe. The registry's clean. The bug lives in how the app handles argv.

   Workaround: there isn't one for connectors

   Connector OAuth flows (Microsoft mail, Figma, Supabase, etc.) have no workaround. The connector flow has to return through codex://oauth_callback, and that's the exact hop that's broken. Nothing client-side fixes it. It needs an app fix.

   The CLI covers base ChatGPT sign-in, nothing more. It shares ~/.codex/auth.json with the desktop app and logs in over localhost loopback / device code, so it skips codex://:

   codex login --device-auth
   # or
   printenv OPENAI_API_KEY | codex login --with-api-key
   

   codex login status then shows the session and the app picks it up. That covers login. Connectors still need the codex:// callback, so they stay dead until the app fix lands.

   Env

   • App 26.527.3686.0 (OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0), exe ...\app\Codex.exe, Chromium 148.0.7778.179
   • Manifest: Executable=app/Codex.exe, EntryPoint=Windows.FullTrustApplication, <uap:Protocol Name="codex" />
   • Windows 11

   👍React with 👍2Reacted by willycotes and Jack
5. Roins-hub

   closed this as completedon Jun 1, 2026
6. Roins-hub

   reopened this on Jun 1, 2026
7. Roins-hub commented on Jun 1, 2026

   

   Roins-hub

   on Jun 1, 2026

   Author

   More actions

   Same here. I’m on OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0 on Windows 11.

   I can confirm this is not fixed by:

   • Repair / Reset from Windows Settings
   • Uninstalling and reinstalling from Microsoft Store
   • Removing HKCU\Software\Classes\codex
   • Re-registering AppxManifest.xml
   • Re-assigning CODEX link type to Codex in Windows Default Apps

   After setting Codex as the default app for the CODEX link type, opening codex://test still launches Codex.exe but fails with:

   "Error launching app"
   "Unable to find Electron app at C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app\c...\test"
   "Cannot find module ...\test"

   So it looks like Windows is routing the protocol to the correct Codex.exe, but Codex/Electron is treating the codex:// URL as the app/module path instead of a deep-link argument.

   This also breaks Supabase OAuth / connector flows for me. I worked around Supabase MCP by using SUPABASE_ACCESS_TOKEN, but connector OAuth flows that require codex://oauth_callback still fail.
8. shumuchen commented on Jun 1, 2026

   

   shumuchen

   on Jun 1, 2026

   More actions

   same here. even codex://test still trigger the problem
9. ax-openai commented on Jun 12, 2026

   

   ax-openai

   on Jun 12, 2026 – with ChatGPT Codex Connector

   More actions

   Closing as a duplicate of #25157.
10. ax-openai

    closed this as duplicateon Jun 12, 2026