Native dialogs immediately lose focus and close on Windows

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Native dialogs/popups in Cursor close almost immediately after being opened on Windows.

For example, when I trigger the Discard File confirmation dialog, the native Windows dialog appears for approximately 200–300 ms and then loses focus and closes, making it impossible to interact with the dialog.

This also affects other popup/dialog interactions in Cursor.

I investigated the issue by monitoring the foreground HWND using the Windows user32.dll APIs.

The behavior is:

Cursor main window (Chrome_WidgetWin_1) has foreground focus.
Cursor opens a native Windows dialog (#32770).
About 200–300 ms later, Cursor’s main Chrome_WidgetWin_1 window becomes the foreground window again.
The native dialog closes as a consequence.

Importantly, no other process takes foreground focus between the dialog and the Cursor main window. Both windows belong to the same Cursor.exe process.

Example captured log:

16:18:43.371
HWND=592114
PID=25092
PROCESS=Cursor
CLASS=Chrome_WidgetWin_1
TITLE=Customize - Baruk.Know.InDoc - Cursor

16:18:46.090
HWND=1771702
PID=25092
PROCESS=Cursor
CLASS=#32770
TITLE=Cursor

16:18:46.320
HWND=592114
PID=25092
PROCESS=Cursor
CLASS=Chrome_WidgetWin_1
TITLE=Customize - Baruk.Know.InDoc - Cursor

So in this reproduction, only ~230 ms after the native dialog receives foreground focus, Cursor’s main window takes foreground focus back.

I also inspected the #32770 dialog’s child controls. For the Discard File dialog they are:

CLASS=DirectUIHWND
CLASS=CtrlNotifySink
CLASS=ScrollBar
CLASS=SysLink
CLASS=Button TEXT=Discard File
CLASS=Button TEXT=Cancel

This confirms that the disappearing window is the actual native Discard File / Cancel dialog.

Steps to Reproduce

  1. Open Cursor on Windows.
  2. Trigger an action that opens a native confirmation dialog, such as Discard File.
  3. Do not click or press anything after opening it.
  4. The dialog appears briefly.
  5. Approximately 200–300 ms later, the dialog loses focus/closes and Cursor’s main window becomes foreground again.

The issue also reproduces without a project/workspace open.

Expected Behavior

The native dialog should remain open and retain focus until I explicitly choose an action such as Discard File or Cancel.

Cursor’s main window should not automatically reclaim foreground focus while a native modal dialog is open.

Operating System

Windows 10/11

Version Information

Version: 3.15.19 (user setup)

Date shown in About Cursor:

Aug 11, 2026, 2:22 AM

CLI output for this installation:

3.15.19
de07bee81cefe43461ebf4f40c3d2d78d15052a0
x64

The problem also reproduced when testing an older Cursor installation, so it does not appear to be exclusively caused by 3.15.19.

Additional Information

The issue started less than three days ago.

Cursor is still usable for normal editing, but dialogs/popups that depend on retaining focus can become effectively unusable because they close almost immediately.

I can provide a screen recording and additional HWND/focus logs if needed.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

6

Hey @ruigiovane Thanks for the detailed HWND capture.

Quick unblock to try now: switch confirmations to render in-window instead of as native Windows dialogs.

  1. Ctrl+Shift+P → Preferences: Open User Settings (JSON)
  2. Add "window.dialogStyle": "custom"

The Discard File confirmation honors this, so it renders inside the Cursor window where nothing at the OS level can pull it away. Applies immediately, no restart.

One thing that would narrow this down: right after the dialog vanishes, is Cursor immediately clickable (dialog actually closed), or briefly frozen until you Alt+Tab and find the dialog still alive behind the main window (just pushed behind)? Those point at different causes.

And that screen recording would help, whenever you get a chance.

7

Thanks! Setting "window.dialogStyle": "custom" worked as a workaround — the confirmation dialogs now stay open and I can interact with them normally.

Regarding your question: the native dialog appears to actually close, rather than just being pushed behind the main window. As soon as it vanishes, Cursor is immediately clickable and responsive. There’s no freeze, and I don’t need to Alt+Tab to regain control.

I also captured the foreground window transition earlier. When reproducing the issue, it looked like this:

Cursor main window (Chrome_WidgetWin_1)
→ native dialog (#32770)
→ ~230 ms later
→ Cursor main window (Chrome_WidgetWin_1)

The PID remained the same throughout the transition, and after the #32770 dialog disappeared, the main Cursor window was immediately interactive again.

So it seems the native dialog is actually being dismissed/closed, not left alive behind the main window.

Thanks again — "window.dialogStyle": "custom" is working perfectly for me as a workaround.