The command line has its own sandbox and its own autonomy flags, and together they form a pair worth understanding as a whole. The sandbox flag turns on execution isolation; the force flag, on the contrary, removes approvals. The first limits capabilities, the second speeds up work. Danger arises not from either alone but from their combination with broad write and network permissions.

A separate group of commands manages the sandbox explicitly: enable, disable, reset the state and run an arbitrary command inside it. The last is more useful than it seems. Running a specific command in the sandbox with read-only paths and network rules is a way to check that the policy really works before you hand the agent a real task.

It helps to see those commands together once. Below are enabling isolation, running tests with read-only access to a neighboring schemas directory, and disabling it. Such a run is exactly the negative test: if the tests pass while writing is closed where writing should not happen, the policy is proved by behavior rather than by the text of a configuration.

Isolation has its own price, and the checks pay it first. A closed network breaks the dependency install, closed paths break access to the shared build cache, and the failure looks like broken code although the code has nothing to do with it. Hence the rule: the list of read-only paths and the network rules are shaped by the real needs of the run, and the first sandboxed launch is made on a state known to be green - so that the effect of isolation can be told apart from the effect of the edits.

The force flag in non-interactive mode deserves particular attention. It allows applying file changes without approval, and in a script that is exactly what is needed: there is nobody to ask. But that is precisely why it must not be combined with broad write and network rights on a shared runner. The combination of no approvals with broad rights turns any untrusted input into a potential action, and on a shared runner someone else's secrets lie nearby.

The right form for such a run is an external disposable environment and credentials with a narrow scope. A container created for the task and destroyed afterwards strips a mistake of consequences: there is nothing to break in it and nothing to carry away. That is cheaper than any attempt to make a broad-rights run safe on a machine where there is something to lose, and it is easier to explain to whoever investigates an incident.