Devcontainer `/tmp/cursor-sandbox-cache` grew to ~1.15 TB inside OrbStack/Docker writable layers

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

Where does the bug appear (feature/product)?

Cursor IDE devcontainers / remote container workflow, specifically Cursor sandbox caches created inside Docker/OrbStack devcontainers.

This appears to involve Cursor-created directories at:

/tmp/cursor-sandbox-cache

inside devcontainers. These caches were persisted in each container’s writable layer and were not automatically bounded or cleaned up.

Describe the Bug

Cursor devcontainers accumulated extremely large build sandbox caches under /tmp/cursor-sandbox-cache inside the container filesystem. Because the directory lives inside the Docker container writable layer, the data persisted across devcontainer restarts and caused the OrbStack backing disk image to grow dramatically.

In this case, the issue consumed over 1 TB of disk space:

  • One devcontainer for zpl-toolchain grew to approximately 1.08TB.
  • Another devcontainer for wunderbarcode grew to approximately 160GB.
  • The host machine’s disk, a 2 TB Mac volume, was nearly full before cleanup.
  • The largest source was not the project workspace itself; it was Cursor sandbox cache data inside container /tmp.

The root cause we identified was repeated sandbox cache directories containing Rust/Cargo build artifacts:

/tmp/cursor-sandbox-cache/<hash>/cargo-target/...

Examples of large files found inside those cache directories included:

/tmp/cursor-sandbox-cache/<hash>/cargo-target/debug/libzpl_toolchain_ffi.a
/tmp/cursor-sandbox-cache/<hash>/cargo-target/debug/deps/libzpl_toolchain_ffi.a

Several individual cache directories were multiple GB each. In the zpl-toolchain container, there were 264 top-level sandbox cache directories, most containing cargo-target subdirectories. The cache had grown to nearly 1 TB.

This is particularly dangerous because the space usage is hidden from normal project cleanup. Cleaning the repository, deleting local target/, removing temporary project artifacts, and shrinking the bind-mounted workspace did not meaningfully shrink the devcontainer because the data was in the container writable layer, not in the project directory.

Steps to Reproduce

I do not yet have a minimal deterministic reproduction, but this is the observed workflow that produced the issue:

  1. Use Cursor IDE on macOS.
  2. Use devcontainers backed by OrbStack/Docker.
  3. Work in Rust-heavy projects where Cursor agents / sandboxed tasks / build-related workflows repeatedly run builds or checks.
  4. Use devcontainers over time across repeated sessions.
  5. Observe Docker container writable layer growth even when the bind-mounted project directory is much smaller.

Diagnostic commands used:

docker ps -a --size --format 'table {{.ID}}\t{{.Names}}\t{{.Status}}\t{{.Image}}\t{{.Size}}'

Before cleanup, relevant containers showed:

stoic_hofstadter   vsc-zpl-toolchain-...   1.08TB (virtual 1.09TB)
trusting_pike      vsc-wunderbarcode-...   160GB (virtual 165GB)

Inspecting inside the zpl-toolchain container:

docker exec stoic_hofstadter sh -lc 'df -h; du -xhd 1 / 2>/dev/null | sort -hr | head -80'

Key result:

1017G /
1009G /tmp
4.5G  /usr
3.7G  /root

Drilling into /tmp:

docker exec stoic_hofstadter sh -lc 'du -xhd 2 /tmp 2>/dev/null | sort -hr | head -100'

Key result:

1009G /tmp
999G  /tmp/cursor-sandbox-cache

Counting and aging the cache directories:

docker exec stoic_hofstadter sh -lc '
  find /tmp/cursor-sandbox-cache -mindepth 1 -maxdepth 1 -type d | wc -l
  find /tmp/cursor-sandbox-cache -mindepth 1 -maxdepth 1 -type d -mtime +7 -print0 | xargs -0 du -sch | tail -1
  find /tmp/cursor-sandbox-cache -mindepth 1 -maxdepth 1 -type d -mtime -8 -print0 | xargs -0 du -sch | tail -1
'

Key result:

264 total top-level cache dirs
978G older than 7 days
21G newer than 7 days

The old cache directories spanned from February 15, 2026 through May 23, 2026, while the newest were from June 3 and June 9, 2026.

Inspecting the type of cached data:

docker exec stoic_hofstadter sh -lc '
  find /tmp/cursor-sandbox-cache -mindepth 2 -maxdepth 2 -printf "%f\n" |
  sort | uniq -c | sort -nr | head -40
'

Key result:

218 cargo-target
87  npm
23  go-build
8   nuget
5   pip
5   node-gyp
1   go-mod

Inspecting large files:

docker exec stoic_hofstadter sh -lc '
  find /tmp/cursor-sandbox-cache -type f -size +500M -printf "%s\t%TY-%Tm-%Td %TH:%TM\t%p\n" |
  sort -nr | head -80
'

Example output:

696026128  2026-02-28 00:00  /tmp/cursor-sandbox-cache/.../cargo-target/debug/libzpl_toolchain_ffi.a
696026128  2026-02-28 00:00  /tmp/cursor-sandbox-cache/.../cargo-target/debug/deps/libzpl_toolchain_ffi.a
664716454  2026-02-26 19:36  /tmp/cursor-sandbox-cache/.../cargo-target/debug/libzpl_toolchain_ffi.a

The second devcontainer showed the same pattern:

docker exec trusting_pike sh -lc 'du -xhd 2 /tmp 2>/dev/null | sort -hr | head -100'

Key result:

147G /tmp
147G /tmp/cursor-sandbox-cache

The wunderbarcode container had 11 top-level cache dirs, all recent, all containing cargo-target directories.

Expected Behavior

Cursor should not allow internal sandbox caches in devcontainers to grow without bounds and persist indefinitely in the Docker writable layer.

Expected behavior would be one or more of:

  • Automatically clean stale /tmp/cursor-sandbox-cache entries after a reasonable TTL.
  • Cap the total size of Cursor sandbox caches per devcontainer.
  • Store large sandbox caches in a location that is explicitly managed and visible to users.
  • Use ephemeral storage for sandbox caches that should not survive devcontainer restarts.
  • Warn users when Cursor-managed devcontainer cache usage exceeds a threshold.
  • Provide a command in Cursor such as “Clean Devcontainer Sandbox Caches”.
  • Avoid duplicating full Rust/Cargo build outputs across many sandbox directories when possible.

The key expectation is that a Cursor-managed cache should not silently consume hundreds of GB or over 1 TB of persistent disk space.

Screenshots / Screen Recordings

No screenshots attached, but the following command outputs document the issue:

Before cleanup:

stoic_hofstadter   1.08TB (virtual 1.09TB)
trusting_pike      160GB (virtual 165GB)

Inside stoic_hofstadter:

1009G /tmp
999G  /tmp/cursor-sandbox-cache

Inside trusting_pike:

147G /tmp/cursor-sandbox-cache

After cleanup:

stoic_hofstadter   15.1GB (virtual 19.3GB)
trusting_pike      3.93GB (virtual 8.39GB)

Host disk free space improved substantially after cleanup:

Before targeted cache cleanup: about 210GiB free
After stale zpl-toolchain cache cleanup: about 831GiB free
After full known sandbox cache cleanup: approximately 1.2TiB free

Operating System

MacOS

Version Information

Version: 3.7.21 (Universal)
VS Code Extension API: 1.105.1
Commit: 517f696d8ab6c53eb04fbfdaae705cd146bf3460
Date: 2026-06-07T21:46:09.237Z
Layout: editor
Build Type: Stable
Release Track: Nightly
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0

For AI issues: which model did you use?

Unknown / multiple Cursor agent sessions over time.

This may involve Cursor’s agent/sandbox behavior rather than one specific model response. The observed directories were named /tmp/cursor-sandbox-cache, and the contents were repeated language build caches, especially Rust/Cargo cargo-target directories.

Additional Information

The cleanup approach that worked was intentionally conservative:

  1. First, confirmed that the project workspaces themselves were bind-mounted from host paths:
/Users/trevorcampbell/code/zpl-toolchain -> /workspaces/zpl-toolchain
/Users/trevorcampbell/code/wunderbarcode -> /workspaces/wunderbarcode

  1. Confirmed the huge data was in the container writable layer, not in the project folders.

  2. Closed the devcontainers / Cursor remote sessions.

  3. Deleted only Cursor sandbox cache directories inside the affected devcontainers.

Initial conservative cleanup for zpl-toolchain:

docker start stoic_hofstadter
docker exec stoic_hofstadter sh -lc \
  'find /tmp/cursor-sandbox-cache -mindepth 1 -maxdepth 1 -type d -mtime +7 -exec rm -rf -- {} +'
docker stop stoic_hofstadter

This reduced stoic_hofstadter from 1.08TB to 37.6GB, leaving 3 recent cache dirs totaling 21G.

After verifying the devcontainer still worked normally, we cleared the remaining known sandbox caches:

docker start trusting_pike stoic_hofstadter
docker exec trusting_pike sh -lc 'rm -rf -- /tmp/cursor-sandbox-cache'
docker exec stoic_hofstadter sh -lc 'rm -rf -- /tmp/cursor-sandbox-cache'
docker stop trusting_pike stoic_hofstadter

Final container sizes:

trusting_pike      3.93GB (virtual 8.39GB)
stoic_hofstadter   15.1GB (virtual 19.3GB)

No project folders, Docker images, or Docker volumes were deleted. The cleanup only removed Cursor’s sandbox cache directory inside the devcontainers.

After cleanup, the devcontainers reopened and appeared to work normally. The main side effect appears to be that Cursor/Rust/Cargo build sandboxes need to rebuild caches.

Why this is problematic

This failure mode is hard for users to discover:

  • The project directory may look reasonably sized.
  • Normal repository cleanup does not affect the Docker writable layer.
  • macOS “System Data” / OrbStack storage can appear huge without explaining that Cursor sandbox caches are the cause.
  • Users may be tempted to delete/rebuild whole devcontainers, which is riskier than clearing stale Cursor-managed caches.

Suggested product fixes

  1. Add automatic TTL cleanup for /tmp/cursor-sandbox-cache.
  2. Add a configurable max size for sandbox caches per container/workspace.
  3. Prefer ephemeral cache storage for sandbox data that does not need to survive container restarts.
  4. Surface cache usage in Cursor’s devcontainer UI.
  5. Add a command palette action to clean Cursor devcontainer sandbox caches.
  6. Avoid creating many independent full cargo-target trees for repeated agent/sandbox runs when a shared/reused target cache is possible.
  7. Emit a warning when Cursor-managed cache directories exceed thresholds such as 10GB, 50GB, or 100GB.

Cursor itself continued working, but the issue nearly filled a 2 TB disk and made the machine difficult to use until the cache bloat was diagnosed and manually cleaned. Without manual intervention, this could plausibly make Cursor/devcontainers unusable or destabilize the host due to disk exhaustion.

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Hi Trevor,

This is a real bug on our side. The build-tool caches Cursor’s sandbox creates under /tmp/cursor-sandbox-cache aren’t cleaned up, and inside a devcontainer /tmp lives in the Docker writable layer, so each session’s cache directory persists across restarts and they pile up over time. Normal project cleanup never touches them, which is exactly why it’s so easy to miss. I’m getting the missing automatic cleanup tracked with our team.

Your cleanup is the right call and safe to keep using: clearing /tmp/cursor-sandbox-cache inside the container only removes build caches (Cargo/npm/Go/etc.), which the tools rebuild on the next run. No project files, Docker images, or volumes are affected.

To keep it from creeping back up:

  • Automate the prune you’re already doing. Your -mtime +7 sweep is a good interim guard. Running it on a schedule, or as a devcontainer postStartCommand, keeps stale session dirs from accumulating.
  • Or keep the cache out of the writable layer. Pointing /tmp/cursor-sandbox-cache at a dedicated Docker volume (or a tmpfs, if you want it fully ephemeral) via a mounts entry in your devcontainer.json makes the growth visible and manageable instead of silently inflating the OrbStack image.

Thanks again for the detailed forensics —-the directory counts, dates, and cache types line up exactly with how these caches are created, which makes this easy to action on our end.