Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
The Cursor 2.6.21 IDE Extension Host terminates (crashes) every time I open Cursor, if it’s either (a) already open at a problematic folder location or (b) if I open that folder after Cursor starts up.
All folders on NTFS C: drive that are accessed from WSL have symlinks created from inside WSL. These create some kind of glitch when read on the cursor extension host services layer, and it crashes. I’m attaching claude’s summary, yes I’m using Claude to figure out why Cursor craps the bed. Note that adding the broken symlinks to the .cursorignore file has no effect. Claude prompt was "Write me up a bug report as professionaly as possible, and sign it “with love, Claude Code”, after having it analyze the Cursor logs, and giving it access via copy paste to the developer console logs.
Steps to Reproduce
Start up Cursor in a folder that has an NTFS symlink created INSIDE WSL’s map /mnt/c working folder, this creates a symlink which doesn’t resolve, and which cursor’s logic should catch and skip instead of raising on it.
Expected Behavior
Cursor should open workspaces that have both working and non-working symlinks without crashing.
Operating System
Windows 10/11
Version Information
Cursor 2.6.21
Additional Information
Claude analysis: (.md format)
Cursor Extension Host Crash: STATUS_STACK_BUFFER_OVERRUN in file_service.node
Product: Cursor IDE
Versions affected: 2.6.20, 2.6.21 (stable channel)
Platform: Windows 11 Pro (10.0.26200), x64
Severity: Critical — renders the IDE partially unusable (extension host crash loop)
Summary
The retrieval-always-local extension host crashes repeatedly with STATUS_STACK_BUFFER_OVERRUN (0xC0000409) when the workspace contains broken NTFS symlinks. The crash originates in the native @anysphere/file-service module (file_service.win32-x64-msvc.node) during workspace indexing. Cursor auto-restarts the extension host, which re-indexes the same workspace and hits the same symlinks, producing an infinite crash loop.
Reproduction
- Create a workspace containing NTFS symlinks whose targets are Linux-absolute paths (e.g.,
/var/llmexploration/output). These are valid symlinks created from WSL but resolve to nothing from the Windows side. - Open the workspace in Cursor.
- The
retrieval-always-localextension host starts, begins indexing, and crashes within ~5 seconds. - Cursor auto-restarts it. Crash repeats indefinitely.
After 3 crashes within 5 minutes, Cursor displays:
“Extension host terminated unexpectedly 3 times within the last 5 minutes.”
Upgrading from 2.6.20 to 2.6.21 (auto-update during the session) did not resolve the issue.
Observed Behavior
Crash telemetry (from DevTools console)
[ext_host_cursor] Extension host crashed undefined {
arch: 'x64',
platform: 'win32',
channel: 'stable',
client_version: '2.6.21',
code: 18446744072635812000, // unsigned representation of 0xC0000409
...
}
Exit code
| Representation | Value |
|---|---|
| Signed 32-bit | -1073740791 |
| Hex | 0xC0000409 |
| NTSTATUS | STATUS_STACK_BUFFER_OVERRUN |
| Unsigned 64-bit (as logged) | 18446744072635812000 |
This is Windows’ fast-fail mechanism — triggered by /GS stack cookie corruption or an explicit __fastfail() call in native code.
Crash timeline (from main.log, session 2 — Cursor 2.6.21)
16:41:12.136 [warning] [CursorProclistService] Native module unavailable; disabling proclist metrics:
Cannot find module './build/Release/cursor_proclist.node'
16:41:22.370 [error] [UtilityProcess id: 2, type: extensionHost, pid: 22584]: crashed with code -1073740791
16:41:27.639 [error] [UtilityProcess id: 5, type: extensionHost, pid: 4380]: crashed with code -1073740791
16:41:32.897 [error] [UtilityProcess id: 8, type: extensionHost, pid: 22484]: crashed with code -1073740791
16:42:42.827 [error] [UtilityProcess id: 11, type: extensionHost, pid: 4992]: crashed with code -1073740791
16:43:01.568 [error] [UtilityProcess id: 14, type: extensionHost, pid: 31948]: crashed with code -1073740791
16:43:11.858 [error] [UtilityProcess id: 20, type: extensionHost, pid: 6648]: crashed with code -1073740791
16:43:16.650 [error] [UtilityProcess id: 23, type: extensionHost, pid: 31324]: crashed with code -1073740791
16:43:21.363 [error] [UtilityProcess id: 26, type: extensionHost, pid: 33284]: crashed with code -1073740791
Eight crashes in two minutes. Each crash takes down the co-hosted extensions:
anysphere.cursor-always-localanysphere.cursor-resolveranysphere.cursor-retrieval
Ripgrep errors preceding crash (from DevTools console)
[Extension Host] Ripgrep warnings:
rg: ./output: The file cannot be accessed by the system. (os error 1920)
rg: ./data\processed: The file cannot be accessed by the system. (os error 1920)
Win32 error 1920 = ERROR_CANT_ACCESS_FILE.
Filesystem state at crash site
$ ls -la output data/processed
lrwxrwxrwx output -> /var/llmexploration/output # BROKEN
lrwxrwxrwx data/processed -> /var/llmexploration/data-processed # BROKEN
These are NTFS symlinks created from WSL pointing to Linux-absolute paths. They are valid within WSL but unresolvable from native Windows processes. The file command reports them as broken symbolic link.
Additional broken symlinks in the workspace
wandb/debug-internal.log (wandb symlink)
wandb/debug.log (wandb symlink)
wandb/latest-run (wandb symlink)
Suspected Root Cause
The native module file_service.win32-x64-msvc.node (20 MB, PE32+ x86-64, Rust/MSVC) in cursor-retrieval/node_modules/@anysphere/file-service/ walks the workspace directory tree during indexing. When it encounters a broken NTFS symlink:
- Windows returns
ERROR_CANT_ACCESS_FILE(1920) when attempting to follow the symlink. - The error handling path in the native Rust code does not gracefully handle this case.
- A stack buffer overrun occurs — either from the invalid symlink target path (
/var/llmexploration/...) being processed as a Windows path, or from unbounded recursion in error recovery. - The /GS stack cookie check fires, calling
__fastfail(), which terminates the process withSTATUS_STACK_BUFFER_OVERRUN.
No crash dump was generated (the CrashDumps directory was empty for Cursor processes, and no crashpad reports were written). This is consistent with __fastfail() — it bypasses normal exception handling and directly terminates the process.
Workaround
Adding a .cursorignore file to the workspace root prevents the indexer from walking the broken symlinks:
output/
data/processed/
wandb/
Expected Behavior
The file indexer should gracefully skip broken or inaccessible symlinks, log a warning, and continue indexing the rest of the workspace. A broken symlink should never cause a native crash.
Recommendations
- Immediate fix: In the native
file_servicemodule, catchERROR_CANT_ACCESS_FILE(and similar symlink-related errors likeERROR_CANT_RESOLVE_FILENAME) during directory traversal and skip the entry with a logged warning. - Defense in depth: Add a top-level SEH handler or Rust panic hook in the extension host native modules to catch stack overflows and convert them to graceful error returns instead of process termination.
- Crash dump generation: When an extension host dies with a non-zero exit code, capture a minidump before the process is torn down. Without dumps, diagnosing native crashes requires reproduction rather than post-mortem analysis.
- Backoff on restart: After 3 consecutive crashes of the same extension host, stop restarting it (Cursor already does this) but also disable indexing for that workspace until the user explicitly re-enables it, rather than crashing again on next Cursor launch.
Environment Details
OS: Windows 11 Pro 10.0.26200
Architecture: x64
Cursor: 2.6.20 -> 2.6.21 (auto-updated during session, crash persisted)
Channel: stable
Electron: (Chromium-based, UtilityProcess model)
Workspace: c:\vsdev\LLMExploration_warpexpert (mixed Windows/WSL project)
Native module: file_service.win32-x64-msvc.node (20,143,584 bytes)
Crepe index: 107 MB cached, 114 commits stale
Collected Artifacts
main.log(two sessions showing crash loop)renderer.log(extension host termination events with extension lists)exthost.log(extension activation timeline, teardown stack traces)Cursor Grep Service.log(indexing activity immediately before crash)Cursor Indexing & Retrieval.log(repo handshake with repo42.cursor.sh)- DevTools console capture (crash telemetry object, ripgrep warnings)
With love, Claude Code
Does this stop you from using Cursor
Yes - Cursor is unusable
