›_ Codex Issues
Codex Issues / #25368

Codex Windows desktop app deep link / OAuth callback bug

Resolved 💬 5 comments Opened May 31, 2026 by Roins-hub Closed Jun 12, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.527.3686.0

What subscription do you have?

GPT-plus

What platform is your computer?

win11-x86

What issue are you seeing?

Codex Windows desktop app deep link / OAuth callback bug

Environment:

  • Windows 11
  • Codex desktop app version: 26.527.3686.0
  • Package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
  • App executable: C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app\Codex.exe

Issue:
Codex desktop app launches normally, but any browser/deep-link callback into Codex fails. This happens when connecting Supabase via OAuth and also when switching/login account flows.

Error shown:
"Error launching app"
"Unable to find Electron app at C:\Program Files\WindowsApps\OpenAI.Codex_26.52...\?code=...&state=..."
or
"Unable to find Electron app at C:\Program Files\WindowsApps\OpenAI.Codex_26.52...\type=click&tag=..."
"Cannot find module ..."

Expected:
The codex:// callback URL should be handled by the running Codex app.

Actual:
Electron appears to interpret the callback/query parameters as the Electron app path/module, then fails to find that module.

Tried:

  • Repair Codex from Windows Settings
  • Reset/reinstall Codex
  • Re-register AppX package
  • Recreate codex:// registry handler
  • Issue persists across account switching and Supabase OAuth flow

Impact:
OAuth/deep-link flows into Codex are broken. Supabase MCP only works after bypassing OAuth and using SUPABASE_ACCESS_TOKEN manually.

What steps can reproduce the bug?

Feedback ID: 019e7310-3e24-7ca2-a019-7a2c0d1f1d11

What is the expected behavior?

Expected:
The codex:// callback URL should be handled by the running Codex app.

Additional information

_No response_

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

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

  • #25157
  • #25188
  • #25203
  • #25297
  • #25284

Powered by Codex Action

Licantrop0 · 2 months ago

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
Roins-hub · 2 months ago

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.

shumuchen · 2 months ago

same here. even codex://test still trigger the problem

ax-openai · 2 months ago

Closing as a duplicate of #25157.