# Background git.exe scans cause 20–30GB+ memory use in Cursor **URL:** \ **Category:** Help\ **Tags:** performance\ **Created:** [November 10, 2026, 6:57am UTC](https://forum.cursor.com/t/background-git-exe-scans-cause-20-30gb-memory-use-in-cursor/177913 "2026-11-10T06:57:40Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Terry\_Teng](https://avatars.discourse-cdn.com/v4/letter/t/6a8cbe/32.png) [@Terry\_Teng](https://forum.cursor.com/u/Terry_Teng)\ **Post date:** [November 10, 2026, 6:57am UTC](https://forum.cursor.com/t/background-git-exe-scans-cause-20-30gb-memory-use-in-cursor/177913/1 "2026-11-10T06:57:40Z")
Hi everyone, 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. ![image](https://us1.discourse-cdn.com/cursor1/original/3X/5/0/5081b4c6d07c5bcb15628f439fd614cb4e0551ca.png) ---
**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\ **Post date:** [November 10, 2026, 9:42am UTC](https://forum.cursor.com/t/background-git-exe-scans-cause-20-30gb-memory-use-in-cursor/177913/5 "2026-11-10T09:42:23Z")
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: 1. Open a terminal in the repo folder. 2. Run `git config core.bigFileThreshold 20m` so git stops line-diffing files over 20MB. 3. Check that `Library/`, `Temp/` and `Logs/` are in your `.gitignore`, and that big binary assets are tracked with Git LFS. 4. 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. ---
**Author:** ![Terry\_Teng](https://avatars.discourse-cdn.com/v4/letter/t/6a8cbe/32.png) [@Terry\_Teng](https://forum.cursor.com/u/Terry_Teng)\ **Post date:** [November 11, 2026, 8:12am UTC](https://forum.cursor.com/t/background-git-exe-scans-cause-20-30gb-memory-use-in-cursor/177913/7 "2026-11-11T08:12:04Z")
Hi Colin, Thanks for your detailed reply. I tried again with UGit closed. The heavy git.exe is started by Cursor. Opening Cursor in this repo runs a git diff: git.exe --no-optional-locks diff --no-ext-diff --no-textconv COMMIT\_HASH HEAD --raw --numstat --no-abbrev -z 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? ---
**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\ **Post date:** [November 11, 2026, 2:02pm UTC](https://forum.cursor.com/t/background-git-exe-scans-cause-20-30gb-memory-use-in-cursor/177913/12 "2026-11-11T14:02:26Z")
Hi @Terry_Teng, thanks! 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 ` and restarting Cursor changes what the panel compares against.