The Cursor window (frameless Agent/glass window; also IDE layout) crashes and exits INSTANTLY with NO error dialog whenever it is maximized — or otherwise made to fill — an external HDMI-connected monitor. It is 100% reproducible on the external monitor and NEVER happens on the built-in laptop panel.
The crash is completely silent: no in-app error, no Windows “Application Error” (Event ID 1000), no WER report, and no crashpad dump is generated for Cursor.
HDR ruled out (external is SDR; the HDR built-in panel does NOT crash)
No DisplayLink / indirect display — direct HDMI
Likely related to a frameless BrowserWindow filling a specific external display output (cf. electron/electron#50040 silent-crash-on-Windows for frameless windows).
Steps to Reproduce
Connect an external monitor via HDMI (2560×1440), scaling 125%.
Move the Cursor window onto the external monitor.
Maximize it (title-bar maximize button, Win+Up snap, drag-to-top, or manually resize to fill the screen).
Cursor exits immediately with no error dialog and no crash report.
100% reproducible on the external HDMI monitor; never on the built-in laptop panel.
Expected Behavior
The window should maximize/fill the external monitor normally without crashing, just as it does on the built-in laptop panel.
I can see that you also wrote in via e-mail, and we’ve filed a bug for this issue!
Cursor is currently on Electron 40.10.3, which contains this fix; unfortunately, it is probably not as simple as a dependency bump.
One thing worth trying: set "window.titleBarStyle": "native" in your VSCode settings and restart VSCode. It would be good to know if it’s indeed linked to “frameless” windows.
Update: I set “window.titleBarStyle”: “native” and fully restarted Cursor (quit the process, not just reload). The setting did take effect — the window now shows a native Windows title bar (File/Edit/View/Help menu bar on the left, native min/maximize/close controls on the right).
However, the crash STILL reproduces 100% when maximizing this window on the external HDMI monitor. So it does not appear to be solely the frameless title bar.
The window that crashes is the standalone Agent window. It crashes on maximize (and also on Win+Up snap / dragging to fill / manually resizing to fill the external monitor). It never crashes on the built-in laptop panel.
Switching primary display between monitors (external crashes either way)
All maximize methods (button / Win+Up / manual resize)
HDR ruled out (external is SDR; the HDR built-in panel does NOT crash)
Now also: window.titleBarStyle = native (native frame confirmed) still crashes
The crash is completely silent: no in-app error, no Windows Application Error (Event ID 1000) / WER report, and no crashpad dump for Cursor.
Environment: Cursor 3.12.30, Electron 40.10.3, Chromium 144.0.7559.236, Windows 11 (10.0.26200), Intel Arc 140T GPU (driver 32.0.101.8860). External: Philips 27E2N1500L, 2560×1440 over HDMI, 125% scaling; built-in panel 2880×1800 @120Hz.
Since it is specific to one external HDMI output and produces no crash log, would a specific log flag or a way to capture the crash (e.g. enabling a particular renderer/GPU log, or a crashpad setting) help you diagnose? Happy to provide whatever traces you need.
Two things would confirm where the issue is coming from:
1. Capture the exit code. First quit Cursor completely (make sure no Cursor.exe processes are left in Task Manager. Then launch it from PowerShell with verbose logging:
$p = Start-Process "$env:LOCALAPPDATA\\Programs\\Cursor\\Cursor.exe" -ArgumentList '--verbose','--enable-logging' -PassThru
*# reproduce the crash (maximize the Agent window on the external monitor), then:*
$p.WaitForExit(); $p.ExitCode
You should see log output mirrored into the PowerShell window. The last lines printed before the window dies are interesting, so please include them.
If the exit code prints 0, it’s a clean programmatic shutdown and the bug is in our window-management code, not the graphics stack. A large number like 3221225477 would point back at a native fault instead.
2. Grab the main process log from the same session. After reproducing, zip up the newest folder under %APPDATA%\Cursor\logs\
The main.log in there should show the shutdown sequence right at the moment of the close.
Result: it’s a CLEAN programmatic shutdown, not a native fault.
Start-Process couldn’t surface the exit code (empty, due to the GUI process handoff on Windows), but the main.log makes it unambiguous — the moment I maximize the (glass/frameless) Agent window on the external HDMI monitor, the window receives a close event and the app quits gracefully. No crash stack, no access violation, no crashpad dump.
Startup restored the window maximized on the external monitor:
window#ctor: using window state {“mode”:1,“x”:175,“y”:46,“width”:1773,“height”:1017,“glassMode”:true}
window#validateWindowState: multi-monitor working area {“x”:0,“y”:0,“width”:2048,“height”:1104}
Then at the moment of the crash:
Lifecycle#window.on(‘close’) - window ID 1
Lifecycle#unload() - window ID 1
Extension host with pid 7896 exited with code: 0
Extension host with pid 18844 exited with code: 0
Lifecycle#onBeforeCloseWindow.fire() - window ID 1
Lifecycle#app.on(window-all-closed)
Lifecycle#app.on(before-quit)
Lifecycle#app.on(will-quit) - calling app.quit()
So this lines up with your “exit code 0 → window-management bug, not the graphics stack” case. It looks like maximizing the glass/frameless window on this specific external display triggers a window close → app quit in the window-management code, rather than a GPU/native crash. Note it also still happens with window.titleBarStyle = native.
So based on the exit code, definitely doesn’t look like a GPU crash.
It’s not Cursor quitting itself either, though. The unload runs as onBeforeUnload (reason: 1), which means “window closed” rather than “app quitting” — the window-all-closed / before-quit / app.quit() lines after it are just what happens once the last window is gone. And window.on('close') looks identical whether the request came from the close button, Alt+F4, or the OS, so it doesn’t tell us the app closed itself.
What does tell us something is the ordering. Last command Cursor runs, in window1_wb0/renderer.log:
15:55:27.213 [trace] Lifecycle#window.on('close') - window ID 1
That command repositions the window buttons, and it runs because you maximized. There’s no close or quit command anywhere between the two, so the close request arrived from outside the app 570ms after the buttons moved.
My theory: on Windows the Agents window doesn’t draw its own minimize/maximize/close buttons (those are the OS-drawn ones), and their position gets recalculated on every maximize. If their clickable areas end up offset from where they’re painted on your display, the click you meant for Maximize lands on Close, which would look exactly like this.
A few things that would confirm or kill it. Try maximizing with Win+Up instead of clicking. If that’s fine, it’s a click-target problem rather than anything about maximizing. Then set “window.controlsStyle”: “custom” and fully restart; that hides the window buttons on Windows, so you’d double-click the title bar to maximize and Alt+F4 to close, but if the crash stops we know it’s them. And does the regular editor window do it too, or only the Agents window?
Update on your theory: it’s NOT a click-target problem, and window.controlsStyle didn’t help either.
Results:
Win+Up (keyboard, no button click at all) ALSO crashes the Agent window. So it can’t be an offset hit-area on the OS-drawn buttons.
Set “window.controlsStyle”: “custom”, fully restarted — still crashes.
Earlier “window.titleBarStyle”: “native” — also still crashes.
Clear pattern across everything we’ve tried:
ONLY the glass/Agent window crashes; the regular IDE/editor window NEVER crashes.
It crashes on maximize via ANY method (maximize button, Win+Up, drag-to-top, manual resize to fill).
100% reproducible ONLY on the external HDMI monitor (Philips 27E2N1500L, 2560×1440, 125%); never on the built-in laptop panel.
Log shows a clean close/quit (onBeforeUnload reason:1, exit code 0), and the last command before the close is cursor.updateGlassWindowsWindowControls, which runs on every maximize.
So this looks like a bug in the glass/Agent window maximize handling (around updateGlassWindowsWindowControls) that only triggers on this external display. It appears to be code-side rather than anything configurable on my end. Let me know if there’s anything else you’d like me to capture.
Next suspect: on Windows the Agents window uses a Mica backdrop (the translucent Windows 11 material) and the regular editor window doesn’t. That’s the cleanest difference between the two, and it goes through DWM rather than Chromium’s GPU path, which would explain why hardware acceleration and the driver update didn’t help.
Could you switch to one of the high-contrast Cursor themes (Cursor Settings → Appearance → Theme) and try again? That would be a big clue!
Confirmed the Agent window background DID become fully opaque with the high-contrast theme (the translucency/Mica is gone), and it STILL crashes on maximize / Win+Up on the external HDMI monitor. So this rules out the Mica/translucent backdrop as the cause.
Recap of the pattern (unchanged): only the glass/Agent window crashes (the IDE window never does), on ANY maximize method (button, Win+Up, drag-to-top, manual resize to fill), and ONLY on this external HDMI display (Philips 27E2N1500L, 2560×1440, 125%). The logs still show a clean close/app.quit (exit code 0 semantics), not a native/GPU crash.
Ruled out so far: hardware acceleration on/off, Intel Arc driver 8132→8860, refresh 75→60Hz, unified scaling, primary-display swap, HDR, titleBarStyle: native, controlsStyle: custom, and now high-contrast/opaque (Mica) too.
Happy to capture anything else that would help narrow it down.
That rules out Mica too, and confirming the background went opaque!
I’m running low on theories. Three asks, if you have the patience:
Try launching with a clean profile and no extensions: cursor --disable-extensions --user-data-dir C:\temp\cursor-test. You have a fair few MCP servers and hooks, and one can drive the app directly, so this rules out that whole surface at once.
Set the Philips display to 100% scaling and retry. You tried both displays at 125%, but 100% changes the maximized window’s logical size a lot, telling us whether this is about size or the display itself.
Grab a fresh log bundle. Everything so far came from that first capture, and your config has changed several times since; I’d like to see if the tail still looks the same!
