Has anyone else run into this? As soon as I open Cursor, my system memory use starts climbing from about 15GB and keeps rising until it passes 45GB.
It seems like Cursor launches git.exe in the background to look up Git changes for the current repo. In some cases that scan walks diffs of tens of thousands of lines, and Cursor’s own memory use often jumps to 30GB or more.
Is this a misconfiguration on my end, or a known issue with how Cursor loads Git changes? Any ideas or workarounds would help. Thanks.
Hi @Terry_Teng, from your screenshot the 27GB is on git.exe, not Cursor itself. The Cursor processes are around 400MB each, and almost all of the git number is in the “shareable” column. That’s large repo files git has mapped while diffing; its private memory is only about 300MB. UGit is open too and also runs git, so it’s worth checking which app started it.
In the meantime, this should calm git down on a large Unity repo:
Open a terminal in the repo folder.
Run git config core.bigFileThreshold 20m so git stops line-diffing files over 20MB.
Check that Library/, Temp/ and Logs/ are in your .gitignore, and that big binary assets are tracked with Git LFS.
Restart Cursor.
If memory still climbs, could you send the command line of the heavy git.exe? In Task Manager, go to Details, right-click a column header, choose Select columns and tick Command line.
COMMIT_HASH is a commit on the remote default branch from about two years ago. Cursor is diffing HEAD against the merge-base with that branch, so the file difference is huge and git keeps taking more memory.
I also tried core.bigFileThreshold 20m locally. It only slowed the climb, and the memory still filled up.
I then merged the remote branch so it includes the newer commits. After that, opening Cursor no longer runs away with memory.
Is this background git process started by Cursor’s built-in Git plugin, and is that the default behavior?
That diff comes from the Changes panel in the Agents Window, not the built-in Git extension behind the Source Control view. And yes, it’s the default: when a repo opens, the panel lists what your branch changed compared to the repo’s default branch, so it diffs HEAD against the merge-base with the branch origin/HEAD points to.
With a merge-base two years back, that single diff has to read most of the repo, and there’s no setting to turn it off today.
Merging the default branch in was the right fix, since it moves the merge-base forward. If the branch you actually work against isn’t the one origin/HEAD points to, running git remote set-head origin <branch> and restarting Cursor changes what the panel compares against.
