Allowlist and denylist: superseded, not guarantees

Cursor historically gave you two fine-grained lists:

• a command allowlist - patterns that are permitted to run, and
• a command denylist - patterns that should be blocked.

These look like the way to express “let it run npx vitest run and git status freely on budgetcli, but never git push or rm -rf.” They are useful as intent, but you have to know exactly how much weight they can bear. Current Cursor CLI permissions still expose allow and deny rules; treat them as pattern-based workflow controls, not as the only security boundary. (CLI permissions)

Sandboxing and command rules answer different questions. The sandbox constrains filesystem and network reach where supported; allow/deny rules control command approval and execution policy. Their exact interaction depends on the current editor/CLI surface and settings, so verify it in the current permissions reference before relying on a particular fallback or approval path.

A deny rule is not a security boundary. A pattern can block an obvious command while missing an equivalent shell expression, script, alias, or indirect tool call. Use deny rules to express intent and reduce accidental execution, but do not treat them as proof that an irreversible action is impossible. The sandbox, a disposable environment, and least-privilege credentials are the stronger controls.

The conclusion is not “lists are useless.” Use allow/deny rules to cut friction and express intent, while putting the real containment in the sandbox or an isolated runner. Do not reach for a deny rule as the thing standing between the agent and an irreversible action. When in doubt, believe the environment boundary, not the pattern matcher.

That leaves one case the local controls can’t cover: work where you want a guarantee rather than a good boundary. For that, you stop tuning settings and change where the agent runs at all. Next: when you need real isolation.