window.confirmBeforeClose causes "Illegal state: service accessor is only valid during the invocation of its target method" error and prevents window from closing

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When setting "window.confirmBeforeClose": "always" in settings.json, confirming window close shows a VSCode-style notification warning indicating Illegal state: service accessor is only valid during the invocation of its target method.

Also, the close confirmation popup is shown even if the property is not set, although this case does not cause the error and does not prevent quitting Cursor.

This affects both the classic IDE and Cursor Glass, although Glass is not showing any warning anywhere - and neither one of them have any error thrown inside of their devtools and logged in the console.

Stack trace is accessible by going into the “Sources” tab and checking “Pause on caught exceptions”, which will show the “Illegal state” error, after a couple of seemingly unrelated ones.

In most cases:

  • If a Glass window is open, you have to force quit the app to close the window, and to quit Cursor.
  • If an editor window is open, you can first close that window, THEN quit the app, which will work as expected.
  • If both Glass and regular editor windows are opened, the regular editor window will close, but the Glass won’t without any feedback or error anywhere. Cursor will NOT quit.

Also, if a Glass window was opened the last time you had to force quit the app, it will reopen automatically on next launch, and you still won’t be able to close it AT ALL.

The only way I found to get rid of it was to launch cursor using cursor --classic in the terminal.

Has been happening for a while and I couldn’t figure out why. Both Stable and Dev channel. Also happens with extensions disabled, does not happen on regular VSCode.

Steps to Reproduce

Set window.confirmBeforeClose to always and try quitting Cursor Editor via Cmd+Q.

Open a Cursor Glass window, try quitting and closing the window - the traffic light button shouldn’t work now.

Expected Behavior

Cursor should quit.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

Version: 3.2.0-pre.35.patch.0
Commit: d1a36a628792b1e615917859916162ea8a2f7e10
Date: 2026-04-17T01:50:29.007Z
Layout: editor
Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Cursor/3.2.0-pre.35.patch.0 Chrome/142.0.7444.265 Electron/39.8.1 Safari/537.36

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report with the video, steps, and stack trace.

I can confirm the bug, I can reproduce it. The root cause is on our side: in the quit handler, ServicesAccessor gets awaited, and after that DI has already invalidated it. Then accessor.get(IDialogService) inside confirmOnShutdown throws an “Illegal state”. For Glass windows this also breaks the close flow, which is why you end up needing a force quit.

We’ve already logged an internal issue, but I can’t share an ETA for the fix yet.

For now, here are a couple workarounds:

  • Remove "window.confirmBeforeClose": "always" from settings.json, the error should go away and quit should work.
  • If a Glass window reopens after a force quit and gets stuck, run cursor --classic in Terminal, like you found.

I’ll reply in this thread once it’s fixed.

7

Hi, happy to help - tried to be as helpful as I could!

Tried looking into the minified stack trace source, but the devtools parser never finished haha. Knowing VSCode internals this isn’t very surprising. I believe Microsoft had a similar issue with Copilot recently too.

I did remove the settings entry, no issues since.
Would like to keep the setting though, as I’m sharing this with a couple Linux / code boxes.
Does Cursor enable quit confirmation by default? VSCode doesn’t and I don’t see any indication that this default was changed.

Quick sidenote - I was surprised to see that Glass is affected, I remembered hearing somewhere that Glass was supposed to help “break free” from VSCode’s architecture.
However, evidently it is still part of it, and workbench is indeed visible in Devtools. Is Glass just a “new” layer rather than a fork, like the current editor?

Thanks for the feedback, glad to know this is getting fixed!