Allow list disappears unless you choose sandbox

Ideas Feature Requests
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Currently there are 3 options for auto-run:
1- ask every time
2- use sandbox and if that fails use allowlist
3 run everything

I feel like 1 is too annoying and 3 is unsafe.
However, option 2 conflates the sandbox with the allow list. I really want to bypass the sandbox because so many things fail there which wastes time, but I want to keep my 3 allow lists (commands, mcp and web sites.)

Steps to Reproduce

Choose auto-run mode: auto-run in sandbox

Expected Behavior

Allow lists should still exist without requiring use of the sandbox

Operating System

MacOS

Version Information

3.1.14 is the version

For AI issues: which model did you use?

All

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey @JenC!

Hoping you can expand on this? There might be some options to help you stay in the sandbox (namely what is configurable in sandbox.json)

7

I have not been recording examples where sandbox operations fail, but I often see it creating python scripts to edit files because it is “restricted from doing that in sandbox mode”

One potentially serious issue that came up yesterday, cursor deleted an untracked file, it was not in the deleted items and I had spent hours on it. I was able to recover it by asking it to replay the chat transcript but I wasted a lot of time trying to figure out what happened and thinking I lost the branch.

This is from the post mortem it created

Cursor sandbox restrictions caused git stash -u to fail. The sandbox blocked filesystem operations on certain paths (.mux/), which caused the -u (include untracked) stash to fail or produce a corrupt entry. This is a known limitation of the Cursor sandbox when performing git operations that touch files outside the workspace write boundary.

The agent dropped the failed stash without verifying its contents. After the -u stash failed, the agent ran git stash drop stash@{0} as cleanup before retrying. Since the -u stash had partially succeeded (removing the untracked file from the working tree and storing it in the stash), this drop was irreversible.

Recommended For Cursor Platform

Issue Recommended Fix
Sandbox restrictions silently break git stash -u Sandbox should either allow stash operations on all workspace-adjacent files or surface a clear error that explains what was blocked.
No built-in safeguard against losing untracked work Consider a pre-flight check before destructive git operations that warns about untracked files that haven’t been committed.