The Run Mode answers the question of what the agent may execute locally without your decision. It is the first lever of trust you hold, and it is set not by taste but by the cost of a mistake in the particular work. The recommended default in current versions is the mode with automatic review: what is allowed runs immediately, shell commands go into the sandbox where possible, and the rest is judged by a classifier.
An honest caveat is needed right away, one the documentation makes itself: the classifier is not a security boundary. It works from a combination of signals and tries to tell the harmless from the dangerous, but that is an assessment, not a prohibition. You cannot build defense against a targeted attack on it: any assessment errs in both directions, and the error that lets something dangerous through comes with no warning. It removes routine approvals, while hard limits are set by other mechanisms - the sandbox, command lists, network rules, hooks.
It helps to lay the modes out in a table once: what each does and when to apply it. Below is that map - from automatic review and the allowlist to full execution without limits. A separate row is needed for the historical mode that asked about every action: it is declared deprecated, and its behavior is achieved with an empty allowlist. That is a typical example of why you check against the current version rather than memory.
| Mode | Behavior | When to apply it |
|---|---|---|
| Auto-review | Allowed runs at once, the shell goes to the sandbox, the rest to the classifier | Ordinary work together with hard limits |
| Allowlist | What is explicitly allowed runs without questions; with sandboxing on, supported shell commands go there too | Regulated commands and a predictable baseline |
| Run everything | No sandbox and no assessment | Only an externally isolated disposable environment |
| Ask every time | A deprecated mode | The equivalent is achieved with an empty allowlist |
The automatic review mode is best read as a procedure with three branches, and it is worth being able to say which branch a given command will take. Branch one: the command is on the allowed list, it runs at once and there will be no questions. Branch two: it is a shell command, and where possible it goes into the sandbox, where it is limited not in its right to run but in its access to files and the network. Branch three: everything else, and here the decision is made by an assessment. The difference matters: in the first two the behavior is deterministic and can be explained, in the third it is not, which is why commands whose mistakes are expensive are worth moving into the first two explicitly.
The allowlist mode is the most predictable and therefore the best choice where regulation matters. There is no probabilistic assessment in it, yet there are still two branches: what is explicitly allowed runs, and with sandboxing enabled supported shell commands go into the sandbox without a question; only what does not go into the sandbox requires a decision. Such a mode is easy to explain in review and easy to verify with a negative test. The price is that it has to be maintained: the list grows with the project, and that is normal work rather than a sign of inconvenience. A useful rule when extending it: allow a specific command for a specific task rather than a whole family of commands, because a broad rule is easy to write and nearly impossible to narrow afterwards.
Full execution without limits deserves a separate warning. It is not a mode without annoying dialogs but the removal of the sandbox and of assessment at once. In it the request, the repository's content and tool output turn into a potential source of any local action. The only sensible place for it is an externally isolated disposable environment without valuable credentials, not the working machine that holds production access.
It is also important to understand the limit of the modes' applicability. They govern the agent's local actions. Cloud agents do not obey them: there the virtual machine's isolation, its own environment and its own network policy apply. Besides, separate protections - for the browser, file deletion, files outside the project and the settings directory - may require approval regardless of the chosen mode. That is not a misconfiguration but a deliberate design: some actions are considered dangerous enough not to depend on the general level of autonomy.
A configured mode is worth verifying rather than taking on faith, and that is done with a negative test. After changing the policy, ask for a knowingly forbidden safe action and watch what happens: the command should either not run or require a decision. Until the refusal has been observed, what you have is an intention, not a policy. The reverse sign is useful too: if the agent suddenly stopped asking about things it used to ask about, the settings have changed - you widened the list, a version was updated, a different configuration was picked up - and that is a reason to look at what is now allowed.
The engineering conclusion is simple: the mode is chosen for the context of the session rather than set once and forever. Familiar code and a cheap mistake allow more autonomy; an unfamiliar project, production access and secrets require less. Changing the mode is ordinary working practice, not an admission of distrust in the tool.
The typical failures are predictable. Treating the classifier as protection and adding no hard limits. Leaving full execution on for the working machine because there are fewer dialogs that way. Allowing families of commands where one would have been enough. Expecting the local mode to govern a cloud agent. And not verifying the policy with a negative test - then you learn its real behavior at the least convenient moment.