Let sandbox.json pin shared build caches to the workspace (Cargo CARGO_TARGET_DIR), not hashed cursor-sandbox-cache dirs

Ideas Feature Requests
, ,
1

Feature request for product/service

Cursor IDE

Describe the request

Sandboxed Agent shells inject cache env vars (CARGO_TARGET_DIR, CARGO_HOME, RUSTUP_HOME, npm/pip/go, …) into hashed paths like:

/var/folders/…/T/cursor-sandbox-cache/<hash>/cargo-target

On a large Rust workspace this is a new multi-GB compile tree per hash. I hit No space left on device (~18 GB free, APFS at 96%) while cargo test compiled wasmtime-wasi into a 2.7 GB sandbox cache. Another ~10 GB hash from an earlier session was still on disk. The agent then considered deleting caches and exporting CARGO_TARGET_DIR to the project target/ — that is a prompt workaround, not a product setting.

I want sandboxed agents to use the same incremental target/ as my own terminal, without disabling the sandbox.

What exists today (and why it is not enough)

sandbox.json has:

{ "enableSharedBuildCache": true }

Docs say this redirects npm/cargo/pip caches to a shared tmpdir so sandboxed and unsandboxed commands share caches. That still:

  1. Lives under temp, not the workspace target/ I already pay for on disk.
  2. Does not document a stable identity across chats/hashes, or a way to set the path.
  3. Does not stop (or document) injecting CARGO_TARGET_DIR, which overrides .cargo/config.toml [build] target-dir.
  4. Is incomplete in practice: staff noted that enableSharedBuildCache: false does not work as expected (Playwright sandbox cache thread).

Workarounds (agent rules that unset/export vars, Legacy Terminal, unsandboxed all permissions) are unreliable: env injection still happens even when FS/network jail is off (env injection report).

Request

Add an explicit, documented way to opt into sharing the host/workspace build directory while keeping sandbox FS and network policy.

Sketch (names flexible):

{
  "enableSharedBuildCache": true,
  "buildCache": {
    "mode": "workspace",
    "cargoTargetDir": "${workspaceFolder}/target"
  }
}

Modes that would cover the cases people already hit:

Mode Behavior
isolated (today’s default) Hashed cursor-sandbox-cache/<id>/…
sharedTmp Current enableSharedBuildCache: one tmpdir, sandboxed ↔ unsandboxed
workspace Do not override CARGO_TARGET_DIR / CARGO_HOME / RUSTUP_HOME (and equivalents) when the destination is already writable via workspace or additionalReadwritePaths

Also useful:

  • Per-tool overrides (cargoTargetDir, cargoHome, …) so a multi-root window can keep one target/ per repo and not mix artifacts.
  • Document which env vars the shell injects (CARGO_TARGET_DIR is the expensive one for Rust incremental builds; CARGO_HOME is a different cache).
  • Honor this when required_permissions: ["all"] is not set; isolation vs sharing should be sandbox.json, not “turn the sandbox off.”
  • Do not require agents to rm -rf sandbox hashes to recover disk.

Security can stay the same: writes still only to workspace + additionalReadwritePaths. Sharing ./target is not a wider FS grant.

Why this is not just “enable the flag”

enableSharedBuildCache is about tmp sharing. Disk-constrained Rust work needs one compile tree, the same one rust-analyzer / my terminal already use. A hashed 3–10 GB copy per agent session is the failure mode.

Environment

  • OS: macOS (Darwin 24.6.0), APFS /System/Volumes/Data
  • Product: Cursor IDE, Agent sandboxed terminal (not Legacy)
  • Cursor version: <paste Help → About>
  • Workload: large Cargo workspace (cargo test pulling wasmtime-wasi / rocci-roc-host)

Related

12

Hey @koliyo, thanks for the feedback! There are a couple of workarounds you can try today, acknowledging that setting enableSharedBuildCache in the user-level .cursor/sandbox.json doesn’t currently work as expected.

1. Per repo: Add .cursor/sandbox.json at the workspace root with:

{ "enableSharedBuildCache": false }

Sandboxed commands will then no longer have CARGO_TARGET_DIR (or the other cache variables) set, so cargo falls back to .cargo/config.toml / ./target, just like in your own terminal. Note that this only applies to commands that actually run inside the sandbox (when the agent requests elevated permissions (network or full access), the command runs outside the sandbox and the redirect still applies). If other tools (npm, pip, Go) start complaining about writing their caches, add those cache folders to additionalReadwritePaths in the same file.

2. Globally: Export CARGO_TARGET_DIR in your login shell profile (for zsh, ~/.zshenv or ~/.zprofile), then fully quit and relaunch Cursor. Cursor picks up your shell environment on launch, and a variable set there takes precedence over the injected value in every agent shell, sandboxed or not. Keep the path inside the workspace (or in additionalReadwritePaths) so the sandbox can write to it.

Would love to know if either of these solves it for you for now.