Windows toast approval action fails: Electron treats notification click parameters as app path when Codex App is minimized

Open 💬 1 comment Opened Jun 2, 2026 by STHxiao

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

26.527.7698.0

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

When the Codex App is running a task and waiting for an approval, I minimized the Codex App window. A Windows notification appeared in the notification/sidebar area asking whether I wanted to approve/allow the action.

After clicking the approval/allow button in the Windows notification, Codex App did not handle the approval correctly. Instead, an Electron error dialog appeared:

Error launching app

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

Cannot find module 'C:\Program
Files\WindowsApps\OpenAI.Codex_26.52.\type=click&tag=13467070148756701452'
The important part is that the notification activation parameters appear to be appended to, or interpreted as part of, the Electron app path:

\type=click&tag=13467070148756701452
This looks like the Windows toast notification click/activation payload is being passed into Electron incorrectly and then treated as an app/module path.

What steps can reproduce the bug?

What steps can reproduce the bug?
Start Codex App on Windows.
Start a task that requires an approval prompt, such as allowing a command or action.
While Codex App is thinking/executing, minimize the Codex App window.
Wait for the Windows notification/sidebar toast asking for approval.
Click the approval/allow button directly in the Windows notification.
Observe that an Electron “Error launching app” dialog appears instead of the approval being handled.
I observed this when Codex App was already running; I was not manually launching the app from the command line.

What is the expected behavior?

What is the expected behavior?
Clicking the approval/allow button in the Windows notification should either:

send the approval back to the already-running Codex App session, or
bring the existing Codex App window to the foreground and let me approve inside the app.
It should not try to launch/load an Electron app from a path containing notification parameters such as:

\type=click&tag=...

Additional information

Additional information
This appears separate from Codex CLI sandbox behavior. The issue seems specifically related to Codex App’s Windows toast notification activation handling.

Workaround: avoid clicking approval buttons from Windows notifications. Restore the Codex App window and approve from inside the app instead.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗