Verified against Cursor · 2026-08-09
Put guardrails on which terminal commands Cursor's Agent mode is allowed to auto-run
A brief establishing which categories of terminal command the agent may run without asking, which require a stated reason first, and which are off-limits entirely for this session, so an agent with command-execution access doesn't run something destructive or irreversible under the umbrella of a broadly worded task.
The prompt
Ready to copy — highlighted parts are example details you can swap.
This session has terminal command access. Before running any command, check it against the categories below rather than assuming a command is fine just because it seems like a reasonable step toward the task. TASK Set up and run the test suite for a package that was just migrated, installing any missing dev dependencies along the way. COMMANDS ALLOWED WITHOUT ASKING FIRST npm test, npm run build, npm run lint, git status, git diff, git log COMMANDS THAT NEED A STATED REASON BEFORE RUNNING, EVEN IF THEY SEEM NECESSARY npm install <package>, git add, git commit (not push), rm on a file inside this project only COMMANDS OFF-LIMITS ENTIRELY FOR THIS SESSION git push --force, rm -rf on anything above this project's own root, any command touching a production database connection string, sudo anything RULES - Before running any command not explicitly in the allowed list, check whether it matches a pattern in the ask-first or forbidden lists, even if its specific form doesn't exactly match the example given — a variant of a forbidden command (a different flag, a different target path) is still forbidden if it does the same underlying thing. - For an ask-first command, state exactly why it's needed for this specific task and what you expect it to do before running it, and wait for acknowledgment rather than running it and explaining afterward. - Never run a command that deletes data, force-pushes, or modifies anything outside this project's own directory, even if it's not explicitly listed — treat "not on the list" as "off-limits" for anything with that shape, not as "presumably fine." - If completing the task seems to require a command from the forbidden list, stop and say so explicitly rather than finding an equivalent workaround command that accomplishes the same effect through a technicality. - Report every command actually run, in order, with its output — not a summary of what you intended to run, the literal commands and their actual results.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Agent mode's terminal access exists specifically so a task doesn't stall every time it needs to install a dependency or run a test, but that same access means a broadly worded task — "set up and run the tests" — carries an implicit blank check to run whatever the agent judges necessary to get there, and "necessary to complete the task" is a much looser bar than "safe to run without asking," especially once the agent hits a blocker and starts trying variations to work around it. Splitting commands into three explicit tiers rather than a single allow/deny list matters because most real commands aren't uniformly safe or uniformly dangerous — installing a dependency is usually fine but worth knowing about, while deleting a file is sometimes exactly what the task needs and sometimes a sign the agent misunderstood the task entirely, and collapsing that middle tier into either "always allowed" or "always ask" either creates unnecessary friction on routine steps or removes the checkpoint on the step most likely to matter. The instruction to check variants of a listed pattern, not just exact string matches, closes the most common way a command guardrail actually fails in practice: an agent blocked from git push --force rarely tries that exact string again after being told no, but it might reach for git push --force-with-lease or an equivalent flag combination that accomplishes the same effect through a technicality not explicitly named, and a guardrail keyed to exact command strings rather than to what a command actually does is trivial to route around by accident, not even necessarily on purpose. Requiring a stop-and-report rather than a workaround when the task seems to need a forbidden command is what actually protects against scope pressure: a task genuinely might need something off-limits to complete as originally described, and the right response to that is surfacing the conflict between the task and the guardrail for a human to resolve, not quietly finding a way around the guardrail that still technically completes the task as asked.
Verified against
Cursor 2.2 · 2026-08-09
Changelog
- 2026-08-09 — Initial publish, verified against Cursor 2.2 Agent mode's terminal auto-run permissions.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
