Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
The “Auto-Run Mode” setting description states: “Tools will auto-run in a sandbox if possible. If not, they will respect the allowlist or ask for approval.”
This implies the Command Allowlist is an active fallback when sandboxing can’t fully apply. In practice, when “Auto-Run in Sandbox” is selected, the Command Allowlist is completely ignored — all commands auto-run without any allowlist check, regardless of what’s in the allowlist.
The UI compounds this by displaying the Command Allowlist field directly below the Auto-Run Mode selector, making it appear active and relevant when it’s actually inert.
Additionally, on Windows, the sandbox’s network egress blocking is explicitly “best-effort” (logged as a warning on every command), yet the allowlist doesn’t kick in as a fallback when sandbox enforcement is weak.
Steps to Reproduce
- Set Auto-Run Mode to “Auto-Run in Sandbox”
- Leave the Command Allowlist empty (or add specific commands)
- Open an agent chat and ask it to run any shell command (e.g.,
echo hello) - Observe that the command runs immediately without approval, despite not being in the allowlist
- Now enable Settings > Legacy Terminal Tool
- Ask the agent to run the same command
- Observe that the command now correctly requires approval (because the allowlist is respected)
Expected Behavior
When “Auto-Run in Sandbox” is selected and a command is not in the Command Allowlist:
- The command should either require user approval, or
- The UI description should clearly state that the Command Allowlist is disabled/ignored under sandbox mode, or
- The Command Allowlist field should be visually disabled/hidden when sandbox mode is active
The current behavior — showing an active-looking allowlist field with description text implying it’s a fallback, while silently bypassing it — is misleading.
Operating System
Windows 10/11
Version Information
Version: 2.5.17 (user setup)
VSCode Version: 1.105.1
Commit: 7b98dcb824ea96c9c62362a5e80dbf0d1aae4770
Date: 2026-02-17T05:58:33.110Z
Build Type: Stable
Release Track: Default
Electron: 39.3.0
Chromium: 142.0.7444.265
Node.js: 22.21.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200
Additional Information
Code-level evidence: In workbench.desktop.main.js, the variable controlling allowlist-based approval is computed as:
const K = useLegacyTerminalTool ?? false;
const J = H && (approvalMode === "allowlist" && P) && !K;
When useLegacyTerminalTool is false (the default), J is forced to false, which skips the allowlist approval path entirely. The code instead sets a workspace_readwrite sandbox policy, which allows unrestricted filesystem writes within the workspace (blocking only writes outside it) and applies network domain filtering — but does not enforce per-command approval.
The TerminalExecutionServiceProxy confirms this: when not using legacy mode and the terminal_ide_shell_exec feature gate is active, it switches to v3 which bypasses the agent’s permissions service.
Windows-specific concern: The sandbox logs "sandbox: warning - direct egress blocking is best-effort on Windows" on every command, indicating network restrictions aren’t fully enforceable. Despite this known limitation, the allowlist still doesn’t activate as a fallback.
Does this stop you from using Cursor
No - Cursor works, but with this issue