›_ Codex Issues
Codex Issues / #25227

Windows Desktop 26.527.3686.0: clicking toast notification launches Codex.exe with raw type=click&tag=... and shows Electron error

Open 💬 7 comments Opened May 30, 2026 by Avisenaprima
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On Windows, clicking a Codex desktop notification can launch a new Codex.exe process with the raw toast activation arguments as the first app argument:

"C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app\Codex.exe" type=click&tag=10373975442458207603

That process then shows an Electron startup dialog:

Error launching app

Unable to find Electron app at C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x...\type=click&tag=10373975442458207603

Cannot find module 'C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x...\type=click&tag=10373975442458207603'

It looks like the notification activation payload is being passed to Electron as an app path instead of being handled as a Windows notification activation event / second-instance argument.

Environment

  • OS: Microsoft Windows 11 Home Single Language
  • OS version: 10.0.26200, build 26200, x64
  • Codex package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
  • Codex app version: 26.527.3686.0
  • Install location: C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0

Observed behavior

  1. Codex desktop is already running normally.
  2. A Windows notification from Codex is clicked.
  3. Windows starts another Codex.exe process via WpnUserService.
  4. The new process command line is:
"C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app\Codex.exe" type=click&tag=10373975442458207603
  1. The new process displays the Electron error dialog above. The existing main Codex window remains usable.

Expected behavior

Clicking a Codex notification should focus/open the relevant Codex window/thread, or no-op gracefully. It should not spawn a new Electron process that treats type=click&tag=... as an application path.

Workaround used locally

To stop the repeated popup, I disabled Windows notifications for Codex and cleared Codex notification history:

$key = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Notifications\Settings\OpenAI.Codex_2p2nqsd0c76g0!App'
New-ItemProperty -Path $key -Name Enabled -PropertyType DWord -Value 0 -Force
[Windows.UI.Notifications.ToastNotificationManager, Windows.UI.Notifications, ContentType = WindowsRuntime] | Out-Null
[Windows.UI.Notifications.ToastNotificationManager]::History.Clear('OpenAI.Codex_2p2nqsd0c76g0!App')

This prevents the user from triggering the faulty notification launch path, but it disables Codex notifications entirely.

Additional notes

  • The main app files exist (app\Codex.exe, app\resources\app.asar, and bundled resources\codex.exe).
  • This appears distinct from full app launch failure: the already-running app continued working; only the notification-click spawned process failed.
  • Possibly related to Windows/MSIX activation handling in the same 26.527.3686.0 release line.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 1 month ago

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

  • #25197
  • #25203
  • #25188
  • #25157

Powered by Codex Action

neusse · 1 month ago

Adding an independent reproduction with a bit more Windows-side evidence. This looks like a specific MSIX/Windows toast foreground-activation handling bug, not an unquoted C:\Program Files path issue.

Environment observed locally:

Codex package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
Codex executable from AppxManifest.xml: app/Codex.exe
AppUserModelID / notification handler: OpenAI.Codex_2p2nqsd0c76g0!App
Manifest entry point: Windows.FullTrustApplication

When the dialog appears, there are two separate Codex process trees:

# Existing healthy app
PID 24592, MainWindowTitle=Codex
"C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app\Codex.exe"

# Bad notification-activation app
PID 9228, MainWindowTitle=Error
Parent PID 5180: C:\WINDOWS\system32\svchost.exe -k UnistackSvcGroup -s WpnUserService
"C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app\Codex.exe" type=click&tag=11575876717883772928

Microsoft-Windows-AppModel-Runtime/Admin logs the launch as Windows activating the packaged app, not Explorer or a broken shortcut:

Event ID 201
Created process 9228 for application OpenAI.Codex_2p2nqsd0c76g0!App in package OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0. [LaunchProcess]

Event ID 211
Added process 9228 to Desktop AppX container ... for package OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0.

The Windows notification database ties the bad argv directly to the Codex toast payload:

Database: %LOCALAPPDATA%\Microsoft\Windows\Notifications\wpndatabase.db
Table join: Notification -> NotificationHandler
NotificationHandler.PrimaryId = OpenAI.Codex_2p2nqsd0c76g0!App
NotificationHandler.HandlerType = app:immersive
Notification.Tag = 11575876717883772928
Payload starts with:
<toast launch="type=click&amp;tag=11575876717883772928">
...
<action activationType="foreground" arguments="type=reply&amp;tag=11575876717883772928" ... />

So the failure path appears to be:

  1. Codex creates a toast with launch="type=click&tag=..." or a foreground action with arguments="type=reply&tag=...".
  2. Windows Push Notifications (WpnUserService) activates the packaged full-trust app.
  3. The full-trust process receives the activation string as a raw argv argument: type=click&tag=....
  4. Electron startup treats that positional arg as the app/module path, producing:
Error launching app
Unable to find Electron app at ...\type=click&tag=...
Cannot find module ...\type=click&tag=...

This also explains why the issue feels random: the main Codex process remains usable; the popup belongs to a second process spawned only by Windows notification activation. It is not a full app launch failure.

The executable path itself is quoted correctly in the command line, so reports that frame this as a Program Files space/quoting problem are probably seeing a symptom, not the cause.

Likely fix area: handle/sanitize MSIX toast foreground-activation argv (type=click&tag=..., type=reply&tag=...) before Electron's app-path resolution, or route those activation args through the existing running instance before Electron tries to load them as an app path.

Current workaround is to disable Codex Windows notifications, but that also removes useful completion/permission notifications, so it is not a real fix.

DimaSergeew · 1 month ago

Additional confirmation from another Windows install. I hit the same Electron startup dialog after clicking/opening a Codex notification.

Environment:

  • OS: Microsoft Windows 11 Home, version 10.0.26200, build 26200, x64
  • Codex package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
  • Codex app version: 26.527.3686.0
  • Install location: C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
  • UI locale: Russian
  • Observed from screenshot on 2026-05-31 around 11:31 local time (Europe/Minsk)

Dialog text from the screenshot:

Error launching app

Unable to find Electron app at C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x6...\type=click&tag=1698302530364409826

Cannot find module 'C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x...\type=click&tag=1698302530364409826'

This matches the same failure mode: Windows notification activation data (type=click&tag=...) is being interpreted as an Electron app/module path instead of being handled as a notification click payload.

liweichao-coder · 1 month ago

I’m seeing the same Windows desktop notification activation failure.

Observed dialog:

Error launching app

Unable to find Electron app at C:\Program Files\WindowsApps\OpenAI.Codex_26.52...\type=click&tag=<redacted>

Cannot find module 'C:\Program Files\WindowsApps\OpenAI.Codex_26.52...\type=click&tag=<redacted>'

This looks consistent with the report here: the toast activation payload type=click&tag=... is being appended/interpreted as the Electron app/module path instead of being handled as a notification activation argument. The main Codex app can still run; the failure is triggered by notification click activation.

OrangeEd1t · 1 month ago

是的，我也遇到了同样的问题，我尝试过修复，但无济于事
codex 版本：26.527.60818

<img width="1116" height="442" alt="Image" src="https://github.com/user-attachments/assets/995dbce5-cc56-4170-8b8e-1b401dd35d31" />

baor87492-star · 1 month ago

I can reproduce the same Windows notification activation path with permission approval actions, not only notification clicks.

Environment observed locally:

  • Windows desktop app installed from Microsoft Store
  • Codex package: OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0
  • Executable: C:\Program Files\WindowsApps\OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0\app\Codex.exe

Repro:

  1. Trigger a command execution permission request in Codex Desktop.
  2. Codex shows a Windows notification popup with approval actions.
  3. Click Allow / approve from the Windows notification popup.
  4. Codex receives the approval and continues, but Windows also shows an Electron error dialog.

Observed dialog shape:

Error launching app

Unable to find Electron app at:
C:\Program Files\WindowsApps\OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0\app\?type=action&action=0&tag=...

Cannot find module:
C:\Program Files\WindowsApps\OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0\app\?type=action&action=0&tag=...

Relevant Codex log sequence confirms the notification action itself is delivered to the running app:

[desktop-notifications] show approval kind=commandExecution requestId=0
[desktop-notifications] show notification actionCount=3 kind=permission notificationId=approval-local-0
[desktop-notifications] notification action actionId=approve actionType=approve notificationId=approval-local-0
[desktop-notifications] emit action actionId=approve actionType=approve notificationId=approval-local-0
[desktop-notifications] action actionType=approve requestId=0
Sending server response id=0 method=item/commandExecution/requestApproval response={"decision":"accept"}

So the issue appears to affect both:

  • type=click&tag=... notification click activation
  • type=action&action=<index>&tag=... notification button activation

Expected behavior: approval from the Windows notification popup should continue to work, but the raw toast activation payload should not be interpreted as an Electron app/module path.

One local experiment adding a user-level CustomActivator for the Codex AUMID suppressed the Electron dialog, but it also broke delivery of the notification action back to the running Codex process, so that is not a viable workaround. This likely needs to be fixed in Codex/Electron/Owl Windows notification activation handling rather than by user registry configuration.

kk9482677-rgb · 1 month ago

Confirming this is still reproducible on a newer Codex Windows build.

Environment

  • Codex Windows app: 26.527.7698.0
  • OS: Windows 11 Core x64, version 10.0.26200
  • Locale: zh-TW
  • MSIX package status: Ok

Reproduction

  1. Run a Codex turn and wait for the Windows turn-complete notification.
  2. Click the notification.
  3. An Electron error dialog appears instead of focusing/opening the conversation.

Redacted error shape:

Error launching app
Unable to find Electron app at ...\type=click&tag=...
Cannot find module '...\type=click&tag=...'

Redacted app log sequence:

[desktop-notifications] show turn-complete conversationId=<redacted> turnId=<redacted>
[electron-message-handler] [desktop-notifications] emit action actionId=none actionType=open notificationId=<redacted>
[desktop-notifications] notification click open notificationId=<redacted>
[electron-message-handler] [desktop-notifications] action actionType=open conversationId=<redacted> requestId=none

Windows app repair and uninstall/reinstall did not resolve the issue. The main app files exist and Codex launches normally when opened directly; the failure remains specific to notification click activation.