Cursor user extension host repeatedly accesses C:\ while idle, consuming ~4 CPU cores and >1 GB RAM

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

While Cursor was idle, the user extension host for load-aws-secrets-cli sustained high CPU and grew to approximately 1.35 GB RAM:

extension-host (user) load-aws-secrets-cli
PID: 42340
CPU: 24% system CPU (~3.8 logical cores on this 16-core system)
Memory: 1348 MB

All other Cursor processes, including the user extension host for the other workspace, were at 0% CPU.

Cursor Extension Bisect completed with:

No extension identified. This might be a problem with Cursor

This rules out installed third-party extensions as the cause. The workload remains in Cursor’s user extension-host process.

An Extension Host CPU Profile was captured. Profile duration: 50.37 seconds; 90,166 samples.

(idle): 49.701 s / 98.68%
(program): 0.251 s / 0.50%

The JavaScript event loop is almost entirely idle, despite the process consuming several CPU cores. This suggests the CPU is in native/background worker threads rather than JavaScript execution.

A Process Monitor capture showed extremely high filesystem activity while idle:

Path / directory              Total events   Opens     Closes
C:\                           549,311        167,181   143,299
C:\Documents and Settings     286,593         95,530    71,648
C:\Users                       95,524         23,881    23,881
C:\                             167,194        47,770    47,770

Neither workspace is rooted at C:\

Steps to Reproduce

No steps, this starts happening straight from startup

Expected Behavior

I didn’t expect cursor to query C:\ root or C:\Documents and Settings at all, especially not repeatedly like this. The user extension host should remain near-idle.

Operating System

Windows 10/11

Version Information

Cursor: 3.16.17 (6b2afae…, stable)

Additional Information

Environment:

  • Cursor: 3.16.17 (6b2afae..., stable)
  • OS: Windows 11, build 10.0.26200
  • CPU: Intel Core Ultra 7 255H, 16 logical processors

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey @Omar_Saad!

Thanks for the report! There are just a few details that would really help us track down where this is coming from.

1. In ProcMon, which process is opening those paths?

Using the capture you already have, go ahead and click one of the high-count rows (C:\, C:\Documents and Settings, or C:\Users), then take a look at the Process Name and PID columns. What we’re really trying to figure out is whether it’s Cursor.exe (or extensionHost), rg.exe, crepectl.exe, or anything with --type=fileWatcher in its command line.

You can check that last one by right-clicking the process and choosing Properties, if it’s available.

2. What’s the full path of the workspace folder?

In particular, does it contain any of these characters: [ ] ( ) { }? Something like C:\Users\you\Projects\[foo]\my-app is the kind of path that tends to cause trouble.

3. Are these environment variables set on your machine?

Specifically CLAUDE_CONFIG_DIR and CODEX_HOME. You can check in PowerShell with echo $env:CLAUDE_CONFIG_DIR; echo $env:CODEX_HOME, and if they come back empty or blank, that’s a useful answer too.

4. Cursor’s indexing log

Finally, in Cursor head to View
Output and pick Cursor Indexing & Retrieval from the dropdown. If you could copy over any lines mentioning FileSystemWatcherService, [external:, or watched roots, that would be great.

Thanks!

7

This is the process that’s doing all the file open/close calls

"C:\Users\saado\AppData\Local\Programs\cursor\Cursor.exe" --type=utility --utility-sub-type=node.mojom.NodeService --lang=en-US --service-sandbox-type=none --dns-result-order=ipv4first --experimental-network-inspection --inspect-port=0 --video-capture-use-gpu-memory-buffer --user-data-dir="C:\Users\saado\AppData\Roaming\Cursor" --standard-schemes=vscode-webview,vscode-file,cursor-rpc-devtools --enable-sandbox --secure-schemes=vscode-webview,vscode-file,vscode-remote-resource,vscode-managed-remote-resource,cursor-rpc-devtools,sentry-ipc --bypasscsp-schemes=sentry-ipc --cors-schemes=vscode-webview,vscode-file,vscode-remote-resource,vscode-managed-remote-resource,cursor-rpc-devtools,sentry-ipc --fetch-schemes=vscode-webview,vscode-file,vscode-remote-resource,vscode-managed-remote-resource,cursor-rpc-devtools,sentry-ipc --service-worker-schemes=vscode-webview --code-cache-schemes=vscode-webview,vscode-file --field-trial-handle=1808,i,12826894661318912597,12576252140384825756,262144 --enable-features=DocumentPolicyIncludeJSCallStacksInCrashReports,EnableTransparentHwndEnlargement,PdfUseShowSaveFilePicker --disable-features=AccessibilityBlockFlowIterator,CalculateNativeWinOcclusion,LocalNetworkAccessChecks,NetworkServiceSandbox,ScreenAIOCREnabled,SpareRendererForSitePerProcess,TraceSiteInstanceGetProcessCreation --variations-seed-version --trace-process-track-uuid=3190709009737917719 --mojo-platform-channel-handle=7880 /prefetch:14

The full path of the workspace folder: C:\Users\saado\Projects\spacemakerai\redacted-project-name

Those two CLAUDE_CONFIG_DIR and CODEX_HOME come back empty

Cursor indexing & retrieval log had none of the two search strings. I attached the full log, but it’s mostly just this:

2026-08-21 13:12:10.539 [info] Relevant feature gate changed; re-evaluating indexing watcher.
2026-08-21 13:12:10.539 [info] Using existing keys for an index
2026-08-21 13:12:10.539 [info] InternalRepoInfo constructor with preferredEmbeddingModel 0
2026-08-21 13:12:10.541 [info] Not creating an indexing watcher: this workspace does not require one.

Cursor Indexing Retrieval.log (12.3 KB)

14

Thanks Omar! That command line confirms the busy process is one of the extension host processes, which narrows things down a lot.

One detail stood out: in your first report the hot process was labeled extension-host (user) load-aws-secrets-cli. That last part is the name of the workspace folder the process belongs to, which looks like your other window rather than the spacemakerai one.

A few more things would pin this down:

  1. What’s the full path of the load-aws-secrets-cli folder, and roughly what’s in it (is it a git repo)?

  2. In ProcMon, for a few of the hot events on C:\ / C:\Documents and Settings:

    • What does the Operation column say (e.g. CreateFile, QueryDirectory)?
    • What’s the Result (SUCCESS vs ACCESS DENIED)?
    • Could you paste 3 or 4 full example paths?

  3. Right-click one of those events, choose Stack, and screenshot the module list. The module names tell us exactly which component is doing the walking.

  4. Does the disk activity stop if you close just the load-aws-secrets-cli window, leaving the other one open?

Thanks!