Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Windows toast Accept/Reject focuses the window but never resolves the pending approval (regression)
Where does the bug appear (feature/product)?
Cursor IDE — Agent command approval / Windows Action Center notifications
Describe the Bug
When an agent requests approval and the Cursor window is not focused, Cursor posts a Windows
toast notification with Accept and Reject buttons. Clicking either button brings the Cursor
window to the foreground, but the accept/reject is never applied. The agent stays blocked on
“Waiting for Approval” indefinitely. The only way to proceed is to manually click the approval
card in the chat pane.
This appears to be a regression of forum topic 157763, which was reported against 3.1.14 and
reported as no longer reproducible in 3.1.15. The symptom matches exactly what Cursor staff
described in that thread: “when clicking ‘Accept,’ the window unminimizes, but the action itself
(whether accept or reject) is never processed.”
Steps to Reproduce
Ensure Auto-Run is disabled, so agent commands require manual approval.
Start an agent task that will request approval for a command.
Minimize or unfocus the Cursor window.
Wait for the Windows toast notification with Accept / Reject buttons.
Click Accept (or Reject).
Expected Behavior
Clicking Accept approves the pending action and the agent continues. Clicking Reject rejects it.
Actual Behavior
The Cursor window comes to the foreground, but the pending action is never resolved and the agent
remains in “Waiting for Approval”.
Diagnostics already ruled out
This is a clean install from the same morning the bug was observed, with a near-default
settings.json (a single unrelated key). The Windows-side plumbing was verified intact:
cursor:// protocol is registered at HKCU\SOFTWARE\Classes\cursor, with the URL Protocol
value present and (default) = URL:cursor.
The handler command is
“C:\Users<user>\AppData\Local\Programs\cursor\Cursor.exe” --open-url – “%1”,
which resolves to the exact executable backing the running processes.
There is no competing machine-wide registration at HKLM\SOFTWARE\Classes\cursor.
Notifications are enabled for AUMID Anysphere.Cursor. No Enabled=0 or
ShowInActionCenter=0 override is present under
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\Settings\Anysphere.Cursor.
That same key records PeriodicNotificationCount = 484, so toast delivery and display work.
Because protocol activation demonstrably fires (the window focuses on click), the failure looks
downstream of activation: the toast payload is not being dispatched to
composer.acceptPendingFromNotification / composer.rejectPendingFromNotification, or that
dispatch is not reaching the composer session that is waiting.
Workaround in use
Binding the two commands directly in keybindings.json resolves the pending approval without
going through the toast:
[
{ “key”: “ctrl+alt+enter”, “command”: “composer.acceptPendingFromNotification” },
{ “key”: “ctrl+alt+backspace”, “command”: “composer.rejectPendingFromNotification” }
]
Operating System
Windows 11 — Windows_NT x64 10.0.26200
Version Information
Version: 3.20.21 (user setup)
Commit: f09fca384ceca23f7bf21f9c23655b162641d740
Date: 2026-09-13T19:02:51.781Z
VSCode Version: 1.128.0
Build Type: Stable
Target: user
OS: Windows_NT x64 10.0.26200
Does this stop you from using Cursor?
Partially. Auto-Run is disallowed by company policy, so every agent action requires manual
approval, which makes the notification approval path load-bearing rather than a convenience.
Shorter version, if you’d rather post something compact
This is a regression of topic 157763, which is closed, so I’m posting here in Support.
On 3.20.21, on a clean install from this morning: clicking Accept or Reject on the Windows toast
brings Cursor to the foreground, but the action is never applied and the agent stays on
“Waiting for Approval”. That matches Colin’s description in post #5 of that topic precisely.
Before posting I ruled out everything on the Windows side:
cursor:// is registered at HKCU\SOFTWARE\Classes\cursor, with URL Protocol present and
(default) = URL:cursor
The handler is “…\AppData\Local\Programs\cursor\Cursor.exe” --open-url – “%1”, resolving to
the exact executable backing the running processes
No competing registration at HKLM\SOFTWARE\Classes\cursor
Notifications are enabled for AUMID Anysphere.Cursor, with no Enabled=0 or
ShowInActionCenter=0 override
PeriodicNotificationCount = 484 on that key, so delivery and display are working
Since activation clearly fires (the window focuses on click), the break looks downstream of the
protocol hop: the payload isn’t reaching composer.acceptPendingFromNotification /
composer.rejectPendingFromNotification, or that dispatch isn’t reaching the waiting composer
session.
Binding those two commands directly in keybindings.json does work, which is my current
workaround:
[
{ “key”: “ctrl+alt+enter”, “command”: “composer.acceptPendingFromNotification” },
{ “key”: “ctrl+alt+backspace”, “command”: “composer.rejectPendingFromNotification” }
]
Worth flagging that Auto-Run is disallowed by company policy here, so every agent action needs
manual approval and this isn’t a convenience issue on our end.
Version: 3.20.21 (user setup)
Commit: f09fca384ceca23f7bf21f9c23655b162641d740
Date: 2026-09-13T19:02:51.781Z
VSCode Version: 1.128.0
Build Type: Stable
OS: Windows_NT x64 10.0.26200
I’ll follow up with devtools console output the next time it happens.
Steps to Reproduce
Ensure Auto-Run is disabled, so agent commands require manual approval.
Start an agent task that will request approval for a command.
Minimize or unfocus the Cursor window.
Wait for the Windows toast notification with Accept / Reject buttons.
Click Accept (or Reject).
Operating System
Windows 10/11
Version Information
Version: 3.20.21 (user setup)
Commit: f09fca384ceca23f7bf21f9c23655b162641d740
Date: 2026-09-13T19:02:51.781Z
VSCode Version: 1.128.0
Build Type: Stable
Target: user
OS: Windows_NT x64 10.0.26200
Does this stop you from using Cursor
Sometimes - I can sometimes use Cursor