Require explicit review for shell actions that delete data, change shared systems, transmit information, or have unclear effects. Permit lower-risk inspection only within a scope you have already reviewed, rather than trusting a command because its name looks familiar.
Know what run modes establish
Cursor documents Run Modes as governing how agent tool calls run and when approval is requested. Auto-review, Allowlist, and Run Everything differ in approval, sandboxing, and classifier behaviour.
The supplied evidence establishes those differences, but not a complete action-by-action approval matrix. Do not infer exact shell permissions from a mode name. Compare the current documented behaviour with your intended boundary before delegating; no setup instructions are assumed here.
Classify effects before commands
As editorial advice, separate proposed shell actions into three groups:
- Inspection: Reading a known file or displaying a bounded diff without changing the project.
- Modification: Editing files, generating artefacts, or changing dependencies.
- Destructive or externally consequential: Deleting files, altering shared resources, publishing, or sending project information elsewhere.
An action can cross categories. A seemingly routine script may perform modifications or network requests. If its contents or target are unknown, classify it as unresolved rather than inspection.
Approval should cover the actual action and target, not become blanket permission for every later command.
Complete a hypothetical command-risk worksheet
Imagine a Chennai developer using a disposable repository containing only synthetic code. The assignment is to correct a label in one sample page.
Record these proposed actions:
- Display the diff for the sample page: expected effect is inspection; evaluate whether output stays within the agreed file.
- Run a project script named “check”: effect is unknown until the script is reviewed; pause rather than assuming it only tests.
- Rewrite the dependency lockfile: modification beyond the label task; request justification and separate approval.
- Remove an output directory: destructive even if recoverable; confirm the exact directory, contents, and recovery plan before considering it.
For each row in your own notes, include target, expected side effects, network involvement, reviewer, and stop condition. This is a worksheet, not a report of executed tests.
Stop when scope changes
Stop if an action reaches outside the agreed repository, introduces an unexplained network destination, or lacks a clear target. Next, ask for a narrower proposal and inspect the relevant script or change plan.
When evaluating access in the coding catalog, check access format and save the terms before buying. Marketplace account/code/token offers are not proof of official subscription equivalence, including any assumed permission behaviour.
Sources and scope
Source material checked 29 October 2026; features/policies may change. Cursor Run Modes documentation establishes mode-dependent approvals, sandboxing, and classifier differences. The command categories and approval worksheet are editorial safeguards, not a documented per-command permission matrix or marketplace guarantee.