Cursor released version 3.6 on May 29 with a new Auto-review run mode. The interesting part was not that an agent could ask fewer questions. It was the order in which the product decided whether a tool call could continue.
According to Cursor’s official run-mode documentation, a call can be handled by an allowlist, run inside a sandbox when eligible, or sent to a classifier that decides whether to allow it, find another approach, or request approval. Cursor also documents that the classifier is non-deterministic and that stricter work should continue to use explicit controls.
That is a more useful model than a single “autonomous” toggle.
Different actions carry different kinds of risk
Reading a file, running a test, installing a dependency, publishing a post, and deleting production data are all tool calls. They are not equivalent decisions.
A binary permission setting erases the information an operator actually needs:
- Is the action read-only or state-changing?
- Is its target limited to the current workspace?
- Can the effect be reversed?
- Are credentials, money, personal data, or another person involved?
- Can the action run in an isolated environment?
- Does the proposed command match the user’s stated goal?
The stronger interface turns those questions into layers. Familiar low-risk actions can proceed under policy. Uncertain work can be contained. Consequential actions can stop for a person.
A sandbox changes the consequence, not the intent
Sandboxes are valuable because they reduce the blast radius of code execution. They do not prove that the code is useful, that a migration is correct, or that a generated artifact should be published.
An agent can safely build the wrong thing inside a perfect sandbox. It can also produce a technically valid patch that contradicts product terminology or removes user-owned work.
That is why isolation and review solve different problems. The sandbox answers “where may this run?” Review answers “is this the change we intend to keep?”
Classifiers are policy helpers, not authority
An LLM classifier can understand more context than a static shell allowlist. It can notice that a command is inspecting logs, that a path is outside the workspace, or that a request involves a destructive operation.
It can also be wrong.
The safe interpretation is to use classification as one signal inside a policy, not as the source of authority itself. High-impact operations still need a deterministic boundary: a restricted credential, a server-side authorization check, a target-specific API, or explicit approval.
The same applies in product design. Hiding a button does not revoke an API permission. A model instruction that says “do not publish” is weaker than a workflow where the draft has no publish capability until a separate approval state is recorded.
Good approval requests carry evidence
Approval prompts become noise when they ask “Allow?” without explaining the effect.
A useful handoff should identify:
- the exact target;
- the state that will change;
- the reason this action is needed now;
- the checks already completed;
- the rollback or recovery path;
- any uncertainty that remains.
That turns approval from a ritual into a decision. It also makes refusal useful: the operator can change the scope, not merely click cancel.
Autonomy is a shape
The broad lesson from Cursor 3.6 is not that every product should copy its run modes. It is that autonomy has multiple dimensions.
An agent can be free to inspect broadly while being narrow about writes. It can run code freely in a disposable environment while needing approval to merge. It can prepare a social post and attach sources without possessing the capability to publish it. It can monitor a deployment continuously while escalating only a state change.
That is the autonomy model I want in the tools I build: fewer interruptions for safe, inspectable work, and a very clear pause before authority expands.