Feature request for product/service
Cursor CLI
Describe the request
Cursor’s power users would love to give agents far more leeway to run commands because it would make agents significantly smarter and more capable.
However, the current permissions model for CLI commands makes it hard to automate almost any CLI use without opening a door to major security or CM vulnerabilities.
There is an effective and cheap solution: Give users the option to write a custom permission script. Of course users could use this stupidly and hurt themselves, but users can already hurt themselves just as badly with Allow All. This introduces no new security risk.
Examples:
Example Use Case 1: Let a Cursor agent review the last git commit in order to generate matching tests.
> Problem: Cursor’s permissions do not allow providing any git access without also providing dangerous git access, because the allow-list model cannot distinguish between safe and dangerous git commands. There is no way to automatically allow git show <commit> while rejecting git reset --hard <commit>.
Example Use Case 2: Let a Cursor agent manage Docker test containers.
> Problem: Cursor’s permissions do not give a way to allow some Docker commands but reject others. There’s no way to allow Docker to create and delete test containers while protecting production containers.
Example Use Case 3: Enforce External File Protection on custom commands
> Problem: Currently, Cursor’s external file protection only applies to the delete command, not CLI commands. This has led to severe data loss for some users.
Further Thoughts:
We really just need two guarantees to safely unlock most workflows:
- Cursor will not impact anything outside the current project without permission
- Cursor will not make dangerous changes to the current project’s change management (version control, deployment, etc.)
With these two guarantees, reasonable change management practices can prevent any serious harm. The previous state can always be recovered.
“Dangerous changes” are hard to define. It’s easy to ban all access to change management, but then Agents may lose useful abilities like reading git history or deploying to test environments. Judgments about what change management is safe will depend on the project and the engineers. Designing rule-based settings that meet the main use cases while preserving usability would probably require a major investment of work. That’s not worth it for now. But by letting the Cursor community define custom permissions scripts, we’ll learn a ton about what use cases are important and how to make good trades on functionality vs. safety. This is critical knowledge to designing a rule-based system for non-power-users.
Fortunately, there is a very easy solution: Give users the option to write a custom permissions script. The permissions script accepts the full command to be run, optionally including metadata like the working directory and the project root path, and returns a success or failure response. When an agent wants to execute a command, it runs the script. A success response grants permission, and a failure response requires Cursor to ask the user.