Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Title:
Severe Windows memory pressure / ~5 GB Page Table caused by extreme whoami.exe process churn from Cursor 3.20.10
Where does the bug appear (feature/product)?
Cursor IDE / in-editor Agent / Agent Store Sync / Windows process and memory management
Describe the Bug
Cursor 3.20.10 on Windows 10 is causing severe system-wide memory pressure and extreme process churn.
The most important finding is that Cursor.exe is repeatedly creating whoami.exe processes using the command:
whoami /user /fo csv /nh
We confirmed this directly with Sysinternals Process Monitor.
In one captured event:
- Cursor.exe PID: 11836
- whoami.exe PID: 7256
- Parent PID of whoami.exe: 11836
- Command line: whoami /user /fo csv /nh
The Process Tree clearly shows:
Cursor.exe (11836)
└── whoami.exe (7256)
This is not an inference: the parent-child relationship was directly observed in Process Monitor.
The system also shows an extremely abnormal Page Table memory usage of approximately 5 GB on a machine with 16 GB of RAM.
RAMMap showed approximately:
- Page Table: ~5.1 GB
- Paged Pool: ~1.3–1.4 GB
- Nonpaged Pool: ~1.45 GB
The Page Table remains at approximately 5.1 GB even after Cursor is closed, although Cursor closing does release some process-private memory.
RAMMap also showed a very large number of historical process records, including tens of thousands of whoami.exe and conhost.exe records. This strongly suggests significant process creation/churn.
The overall result is severe system-wide paging and slowdown. When the problem occurs, Windows becomes extremely sluggish and Cursor becomes practically unusable. Closing Cursor significantly improves system responsiveness.
Steps to Reproduce
- Start Windows 10 with Cursor 3.20.10 installed.
- Open Cursor and use the Agent functionality.
- Let Cursor remain open for a short period.
- Monitor the system with Sysinternals Process Monitor filtered to whoami.exe.
- Observe whoami.exe processes created by Cursor.exe.
- Monitor RAM usage with Task Manager / RAMMap.
- Observe the abnormal Page Table growth/usage and severe memory pressure.
Expected Behavior
Cursor should not continuously create large numbers of short-lived whoami.exe processes in a way that causes extreme process churn and potentially contributes to abnormal Page Table usage and system-wide memory pressure.
If Cursor needs to determine the current Windows user/SID, that information should ideally be cached or otherwise obtained without repeatedly spawning short-lived processes at a high frequency.
Actual Behavior
Cursor.exe creates whoami.exe with:
whoami /user /fo csv /nh
We directly confirmed the parent-child relationship:
Cursor.exe (PID 11836)
└── whoami.exe (PID 7256)
The machine subsequently experiences severe memory pressure, paging, and system-wide slowdown.
Additional technical findings
We inspected Cursor’s local Agent Store Sync behavior and found evidence that Agent Store Sync is active in Cursor logs.
The logs contain entries such as:
- Agent store harness enabled by agent_store_sync_client
- Agent store sync ready
- pathSyncRequestPollMs: 250
- pathSyncRequestWaitPollMs: 50
- syncDebounceMs values
- sync rounds becoming stalled
- lock_lost
- running → passive
- relinquished write lock (lock_lost)
We also inspected the installed Cursor extension code and found code paths that use:
execFileSync(“whoami”, [“/user”, “/fo”, “csv”, “/nh”])
There is also an exclusive mutation claim polling mechanism using a periodic timer.
This makes Agent Store Sync a strong candidate for the observed process churn, although I am not claiming that it is necessarily the sole cause of the 5 GB Page Table usage. I would like the Cursor team to investigate the relationship between Agent Store Sync polling, repeated whoami.exe creation, process churn, and the abnormal Page Table usage.
System Information
OS:
Windows 10 Pro 22H2
Build 19045.7725
CPU:
Intel Core i7-6700 @ 3.40 GHz
4 cores / 8 logical processors
RAM:
16 GB (15.9 GB usable)
Cursor:
3.20.10
Installed/updated September 10, 2026
Observed memory state
At peak usage:
- RAM usage: approximately 96–98%
- Available physical memory: sometimes below 500 MB
- Hard page faults: hundreds per second
- Disk active time: up to 100%
- Page Table: approximately 5.1 GB
- Paged Pool: approximately 1.3–1.8 GB
- Nonpaged Pool: approximately 1.4–1.45 GB
The issue is severe enough that Cursor can make the entire Windows system practically unusable.
Evidence attached
-
Process Monitor screenshot showing:
whoami.exe PID 7256
Parent PID 11836 -
Process Monitor Process Tree showing:
Cursor.exe (11836)
└── whoami.exe (7256) -
Process Monitor CSV capture of the whoami.exe process.
I can provide the original Process Monitor PML trace and additional RAMMap/PoolMon captures if needed.
Request
Please investigate whether the Agent Store Sync / agent_store_sync_client implementation in Cursor 3.20.10 can cause excessive spawning of whoami.exe processes on Windows, and whether this can contribute to the extreme process churn and abnormal Page Table memory usage described above.
I would particularly appreciate confirmation from the Cursor team of:
- Whether this whoami.exe polling behavior is expected.
- Whether it is a known issue in Cursor 3.20.10 on Windows.
- Whether Agent Store Sync is responsible for this behavior.
- Whether there is a recommended fix or upcoming fix.
- Whether you need the full PML trace, Cursor logs, RAMMap snapshot, or any additional diagnostics from my machine.
Does this stop me from using Cursor?
Yes. When the problem occurs, Cursor becomes practically unusable and the resulting Windows memory pressure makes the entire system extremely slow.
Steps to Reproduce
- Start Windows 10 with Cursor 3.20.10 installed.
- Open Cursor and use the Agent functionality.
- Leave Cursor running for a short period.
- Run Sysinternals Process Monitor and filter for whoami.exe.
- Observe that whoami.exe processes are created by Cursor.exe.
- In Process Monitor → Process Tree, inspect the parent-child relationship.
- Observe Cursor.exe (PID 11836) creating whoami.exe (PID 7256).
- Monitor system memory with Task Manager and RAMMap.
- Observe severe memory pressure, paging, and an abnormally large Page Table (~5.1 GB).
The issue becomes severe enough that Windows becomes extremely sluggish and Cursor becomes practically unusable.
Expected Behavior
Cursor should not repeatedly spawn large numbers of short-lived whoami.exe processes at a high frequency in a way that causes excessive process churn and severe system-wide memory pressure.
If Cursor needs the current Windows user/SID, the information should preferably be cached or obtained without repeatedly spawning short-lived processes.
Screenshots / Screen Recordings
Operating System
Windows 10/11
Version Information
Cursor 3.20.10
Additional Information
Additional diagnostic evidence:
The issue is not simply high application memory usage. RAMMap showed an unusually large Page Table of approximately 5.1 GB on a system with 16 GB RAM.
After closing Cursor, Cursor’s process-private memory decreased, but the Page Table remained at approximately 5.1 GB. This suggests that the problem involves system-level process/page-table churn rather than simply Cursor retaining several GB of private memory.
We also found approximately 2.3 GB of disk space used by Cursor’s local Agent CLI version cache under:
%APPDATA%\Cursor\User\globalStorage\anysphere.cursor-agent-worker\agent-cli.local\share\cursor-agent\versions
This consists of multiple cursor-agent versions and does not appear to be the direct cause of the RAM problem, but it is included here for completeness.
Cursor logs also contain Agent Store Sync activity, including stalled sync rounds and lock_lost/passive transitions.
The direct Process Monitor evidence is the strongest finding: Cursor.exe (PID 11836) created whoami.exe (PID 7256), with the command line:
whoami /user /fo csv /nh
Does this stop you from using Cursor
Yes - Cursor is unusable