What it can do without asking

Before you configure anything, three separate mechanisms are already deciding what the agent may do. Knowing which one stopped something is the difference between a fix and a workaround.

Commands are confined — where a sandbox exists

Where a backend is available, tool execution runs under an OS-level sandbox that confines writes to the working directory and the temp directory. A command that tries to write elsewhere fails, without your involvement.

Which backend you get depends on the platform:

The Linux condition is not academic. Stock Ubuntu and GitHub's runners set kernel.apparmor_restrict_unprivileged_userns=1, which makes the namespace setup fail — so bwrap being installed is not enough on its own.

Where no backend is available, Snaga starts anyway and says so, and commands run with whatever your user account can reach. That is the right default for a person who can read the warning and the wrong one for a machine that cannot, which is what the second flag below is for.

Find out which one you have

snaga selftest

  ✓ sandbox         seatbelt enforcing

The level it reports is always the one in force, never the one requested. If enforcement is absent, this says so rather than repeating what was asked for — a claim of protection with nothing behind it is worse than an honest absence of one.

The two flags

snaga --danger-full-access    # no sandbox, even where one exists
snaga --require-sandbox       # refuse to start when no backend is available

The first is spelled unpleasantly on purpose.

The second is the one to reach for in CI and unattended runs, and the table above is why: a pipeline that assumes confinement gets none on Windows and may get none on Linux, silently, with only a log line to say so. --require-sandbox turns that into a refusal to start.

Dangerous commands are blocked, not merely flagged

Every shell command is matched against a rule set of 28 built-in patterns. Rules carry one of three risk classes:

The shipped defaults use only the latter two: nothing is listed as safe, because safety here is the absence of a match, not an entry. safe exists for rules you write yourself — see Changing the rules.

By default, escalation is off, and that collapses privileged and self_destructive into the same outcome: hard block. Not a prompt, not a warning — the command does not run.

A command matching no rule is allowed. The list is a denylist of shapes known to be dangerous, not an allowlist of blessed commands, so ordinary work is not interrupted.

Matching is case-insensitive, so a pattern cannot be evaded by capitalisation.

Dangerous tools ask a human

Separately from the shell, tools that can cause damage require confirmation before they run. When a task came in over the bridge, that confirmation goes to the person who sent it — see Approvals and safety.

The gate reads the tool's arguments, not just its name. A tool whose name looks harmless but whose action parameter is destructive still asks. A name-based check would not see that, and once did not.

When nobody can answer

Non-interactive runs — --prompt, --autonomy, --yolo — have no human to ask. Rather than dead-ending at a prompt nobody will answer, a request for confirmation resolves immediately against a configured default, and that default is deny.

This matters for scripts: a snaga -p run does not hang waiting for an answer, and it does not silently proceed either.

What none of this protects against

These mechanisms bound what a command can reach. They do not judge whether the work is correct, and they do not undo anything.

A missing sandbox does not remove the other two. The shell policy and the confirmation gate are separate mechanisms and apply on every platform: a host with no sandbox backend still blocks a fork bomb and still asks before a dangerous tool runs. It just does not additionally confine where a permitted command may write.

• To stop the agent writing at all, use Plan mode.
• To undo what it wrote, use checkpoints.
• To change the rules themselves, see Changing the rules.