Shell Tool Injects 30+ Sandbox Cache Environment Variables Even with required_permissions: ["all"], Breaking Build Tools

[Chenxi_Shi]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The Shell tool unconditionally injects 30+ sandbox cache environment variables (GRADLE_USER_HOME, CARGO_HOME, NPM_CONFIG_CACHE, etc.) pointing to temporary directories under /var/folders/…/cursor-sandbox-cache/…, even when required_permissions is explicitly set to [“all”] which should completely disable sandboxing.

This breaks build tools and package managers that rely on global caches. For example, GRADLE_USER_HOME redirection causes Gradle builds to completely ignore the user’s ~/.gradle cache, resulting in massive performance degradation as every build becomes a cold start.

The documentation states that required_permissions: [“all”] “disables the sandbox entirely”, but environment variable injection still happens unconditionally.

Steps to Reproduce

1. In Cursor Agent mode, execute a shell command with required_permissions: [“all”]
2. Run: env | grep -i “cursor-sandbox-cache” | wc -l
3. Observe 30+ environment variables pointing to sandbox cache directories
4. Specifically check: echo $GRADLE_USER_HOME
5. Expected: Empty or user’s actual ~/.gradle
6. Actual: /var/folders/…/cursor-sandbox-cache/…/gradle

The affected variables include:

• GRADLE_USER_HOME (critical for Android/Java projects)
• CARGO_HOME, RUSTUP_HOME
• NPM_CONFIG_CACHE, YARN_CACHE_FOLDER, PNPM_STORE_PATH
• PIP_CACHE_DIR, POETRY_CACHE_DIR, PIPX_HOME
• GEM_HOME, BUNDLE_PATH
• GOCACHE, GOMODCACHE
• And 20+ more build tool cache directories

Expected Behavior

When required_permissions: [“all”] is specified, the sandbox should be COMPLETELY disabled, including:

1. No filesystem restrictions (currently works)
2. No network restrictions (currently works)
3. No environment variable injections (CURRENTLY BROKEN)

Users should have full control over their build environment. If cache isolation is desired, it should be opt-in, not forced even with “all” permissions.

At minimum, provide a way to truly disable sandbox environment variable injection, or document this limitation clearly in the Shell tool description.

Operating System

MacOS

Version Information

Version: 2.4.36 (Universal)
VSCode Version: 1.105.1
Commit: f9919bf991f247689f9ead605b5c5a3239a2a790
Date: 2026-02-12T21:00:33.976Z
Build Type: Stable
Release Track: Early Access
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Darwin arm64 24.6.0

For AI issues: which model did you use?

Claude Sonnet 4.5
This issue affects the Shell tool infrastructure, not model behavior.

Additional Information

Impact severity: HIGH for developers working on projects with large dependency caches (Gradle, npm, cargo, etc.)

Current workaround: Manually override environment variables before every command, e.g.:
GRADLE_USER_HOME=~/.gradle ./gradlew build

This defeats the purpose of having an AI agent that can run commands autonomously.

Related: This also affects CI detection (CI=1 is injected), causing some tools to behave differently than expected.

Does this stop you from using Cursor

No - Cursor works, but with this issue

[deanrie]

Hey, thanks for the report. It looks like there’s a real gap in how required_permissions: ["all"] works: filesystem and network restrictions get turned off, but environment variable injection still happens unconditionally.

As a workaround that you already found (adding a real env var before commands), you can also try adding this to your .cursor/rules:

When running shell commands for builds, always unset sandbox cache variables first:
unset GRADLE_USER_HOME CARGO_HOME NPM_CONFIG_CACHE && <actual command>

Not perfect, but it’s a bit less manual than overriding it for every command.

One question: are you using the terminal in sandbox mode, or the legacy terminal? You can check in Cursor Settings (gear icon in the top right) > Agents > Terminal. If you switch to Legacy Terminal Tool (Cursor Settings > Agents > Legacy Terminal Tool), env var injection might not apply. Worth checking.

Let me know how it goes.