Cursor fills /tmp with ~2.9 GB cursor-sandbox-cache, causing shell “Disk quota exceeded” errors

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I’m running Cursor on Ubuntu and started seeing shell commands fail with:

--: line 20: cannot create temp file for here-document: Disk quota exceeded

My actual root filesystem has plenty of free space:

$ df -h

Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv  455G   44G  388G  11% /
tmpfs                              3.6G  2.9G  734M  80% /tmp

So I checked inode usage as well:

$ df -i /tmp

Filesystem      Inodes  IUsed  IFree IUse% Mounted on
tmpfs          1048576 127579 920997   13% /tmp

Inodes were not exhausted.

I then checked what was consuming /tmp:

$ sudo du -xhd1 /tmp 2>/dev/null | sort -h

0       /tmp/.ICE-unix
0       /tmp/.X11-unix
0       /tmp/.XIM-unix
0       /tmp/.font-unix
0       /tmp/claude-1000
0       /tmp/vscode-ah-7606688cb11a
4.0K    /tmp/org.chromium.Chromium.yZ6Xap
252K    /tmp/gh-cli-cache
1.8M    /tmp/node-compile-cache
3.5M    /tmp/snap-private-tmp
2.9G    /tmp
2.9G    /tmp/cursor-sandbox-cache

/tmp/cursor-sandbox-cache accounted for essentially the entire 2.9 GB.

After closing Cursor and deleting that cache:

sudo rm -rf /tmp/cursor-sandbox-cache

/tmp immediately returned to normal:

$ df -h /tmp

Filesystem      Size  Used Avail Use% Mounted on
tmpfs           3.6G  5.7M  3.6G   1% /tmp

So the issue appears to be that cursor-sandbox-cache can grow to several gigabytes without being cleaned up or bounded, which is particularly problematic on systems where /tmp is a RAM-backed tmpfs.

Once /tmp became heavily occupied, I started getting unrelated-looking shell failures because Bash could no longer create temporary files for here-documents.

I have also previously seen this error while using Cursor:

bash: fork: Resource temporarily unavailable

I’m not sure whether that is related, but I’m mentioning it in case the sandbox/agent infrastructure is leaking more than one kind of resource.

Expected behavior

Cursor should clean up stale sandbox cache entries and/or enforce a reasonable maximum cache size so that it cannot consume most of the system’s /tmp filesystem.

Actual behavior

/tmp/cursor-sandbox-cache grew to approximately 2.9 GB, occupying about 80% of a 3.6 GB /tmp tmpfs, until shell operations began failing.

Workaround

Deleting:

/tmp/cursor-sandbox-cache

restored /tmp usage from 80% to 1%.

Environment

  • OS: Ubuntu Linux
  • /tmp: tmpfs, 3.6 GB
  • Cursor version: [add cursor --version output here]
  • Kernel: [add uname -a output here]

Happy to provide additional diagnostics if there are particular Cursor logs that would help identify what is generating or retaining the sandbox cache.

Steps to Reproduce

  1. Run Cursor on Ubuntu with /tmp mounted as a tmpfs. In my case:

    tmpfs  3.6G  ...  /tmp

  2. Use Cursor normally for an extended period.

  3. Observe /tmp/cursor-sandbox-cache growing over time:

    du -sh /tmp/cursor-sandbox-cache
df -h /tmp

  4. In my case, cursor-sandbox-cache eventually reached approximately 2.9 GB, consuming about 80% of the 3.6 GB /tmp filesystem:

    2.9G    /tmp/cursor-sandbox-cache

  5. At this point, shell commands launched while using Cursor began failing with errors such as:

    --: line 20: cannot create temp file for here-document: Disk quota exceeded

  6. Close Cursor and remove the cache:

    sudo rm -rf /tmp/cursor-sandbox-cache

  7. Check /tmp again:

    df -h /tmp

    Usage immediately drops from approximately 2.9 GB / 80% to approximately 5.7 MB / 1%, and the shell error disappears.

Note: I have not yet identified a single Cursor action that deterministically triggers the growth. The issue appears after normal/extended Cursor usage. I can monitor the directory to narrow down which Cursor operation causes cursor-sandbox-cache to grow.

Operating System

Linux

Version Information

Version 3.16.17

For AI issues: which model did you use?

Auto

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Happening on MacOS too. I don’t really know what it needs 2.9 GB for.

8

Thanks for the detailed report, and thanks for the macOS confirmation as well. What you’re seeing isn’t intended, and it isn’t caused by anything in your setup. Cursor’s sandbox redirects generated build-tool caches, including npm, Cargo, and pip caches, into cursor-sandbox-cache. On your 3.6 GB RAM-backed /tmp, that cache grew enough to trigger the temporary-file failure you saw. We’re tracking the excessive cache growth and missing cleanup. I don’t have a timeline to share yet, but I’ll post here when there’s an update.

Your cleanup is the best current recovery step. First, quit Cursor and stop any active Agent commands, then run:

rm -r -- /tmp/cursor-sandbox-cache

If that fails due to permissions, retry the exact same command with sudo. This removes generated build caches, not project files, though affected tools may need to rebuild their caches during the next run. You can monitor it before it causes another failure with:

du -sh /tmp/cursor-sandbox-cache 2>/dev/null

This workaround restores the space but does not prevent the cache from growing again. The diagnostics you’ve already provided are enough for this issue.

The earlier bash: fork: Resource temporarily unavailable message may have a separate cause. If it returns while /tmp still has ample capacity, please post the surrounding output and current df -h /tmp.

9

Is there any way to point this at a different directory? My cargo build creates a 40GB target directory in /tmp/cursor-sandbox-cache which almost fills up /tmp

Better yet I’d prefer an option to disable it as the repo already has a target directory which can be used for incremental builds

10

This can get considerably out of hand on system HD too. I just received a system warning from my Mac the 2 TB drive was almost full. Found the culprit to be at /private/var/folders/../../../cursor-sandbox-cache using a whopping 891 GB