Permissions & safety

Pick the mode that fits the situation

A permission mode decides how much the agent can do on its own before it has to stop and ask you. The right choice depends on how much you trust the work in front of you: a familiar project you own is different from a repository you just cloned. You set one mode and can change it at any time; it shapes the whole policy rather than forcing you to answer the same question over and over.

All four modes share the same hard floors: actions that touch files outside your workspace, broad destructive commands, and generic high-risk network calls always come back to you. Parsed scoped network shell flows, including repo VCS, package bootstrap, and read-like diagnostics/downloads, can clear in Auto when the command stays inside those boundaries. The mode changes the everyday friction, not those safety limits.

• default, everyday workspace work: the agent reads, searches, edits, runs local shell, runs builds/tests, and uses git inside your workspace without asking. Web access, MCP tools, destructive actions, and anything reaching outside the workspace still prompt. The right starting point for most sessions.
• auto_review, fewer routine interruptions: same workspace defaults, but eligible prompts are first shown to a small reviewer model that can approve clearly-safe requests so they don't interrupt you. The reviewer can only approve a fixed set of low-risk capabilities; anything risky still reaches you.
• full_access, trusted work, fewer prompts: allows the full set of capability defaults with far fewer interruptions. Choose it only for work and a repository you fully trust, since it relaxes the guardrails. (In this mode the shell OS sandbox is turned off.)
• custom, set each capability yourself: decide per capability, reads, searches, edits, shell, web, MCP, git, compiler, destructive actions, whether each is allowed, asks first, or is denied. Use it when no preset matches your comfort level.

Plan mode: explore freely, mutate never

Plan mode is a separate axis from the permission mode above: it's a session switch you flip with /plan (and back with /build) when you want a plan before any change lands. The common idea that it only allows reading and searching is too narrow. Plan mode draws its line at mutation, not at running things, so it can ground a plan in evidence rather than guesses.

While Plan mode is active, non-mutating work runs on the normal permission path: reads, searches, and static inspection, but also read-only shell, read-only git (status, diff, log, show, branch), and checks or builds that only write ordinary compiler artifacts. What's refused at the permission boundary is anything that mutates: file edits, applying patches, formatters and codegen, and any shell command that writes outside the build's own caches. A command that's neither proven read-only nor a known mutation isn't silently allowed, it comes to you as an ordinary approval prompt.

The one editable target in Plan mode is the active plan file itself, so the agent can refine a proposal in place. If you ask it to implement from inside Plan mode, it won't edit anything; it tells you to switch to Build mode first.

• Allowed without asking: read, search, static inspection, read-only shell and git, and non-mutating checks/builds (for example cargo check, build, test, rustc, cargo fmt --check, cargo clippy without --fix).
• Refused at the boundary: file edits, apply-patch, formatters and codegen, and mutating shell, even commands you'd otherwise have permission to run.
• Unproven commands: a command that's neither clearly read-only nor clearly mutating routes to a normal approval prompt rather than being denied outright.

How the reviewer mode helps

auto_review exists to cut the number of times you're interrupted for obviously-safe steps without handing over the keys. When a permission prompt would normally come to you, a small, fast model first looks at it together with a short slice of recent context and a fixed policy, and answers allow, deny, or “ask the human.”

Its power is deliberately narrow. It can only auto-approve a fixed set of capabilities; for anything else, its “allow” is ignored and the request still comes to you. It can never auto-approve destructive actions, generic high-risk network or MCP calls, or writes outside your workspace. Parsed scoped network shell flows, including repo VCS, package bootstrap, and read-like diagnostics/downloads, can clear through high risk when every segment stays inside those boundaries. The point is to remove busywork, not to widen what's allowed.

The shell sandbox: what an approved command can touch

Permissions decide whether a command is allowed to start. The sandbox decides what that command can do once it's running. Even a command you approved is run inside an OS-level boundary, so a build script or project tool can't quietly reach beyond the work at hand.

Inside the sandbox a command can read the files it needs (Squeezy doesn't confine reads to an allowlist, so build tools find their configs and caches without per-tool tuning) and can read and write inside your workspace and temporary directories, enough for normal builds, tests, and formatters. What it cannot read are your sensitive files: SSH keys, cloud credentials, package-manager logins, and .env files are blocked. The network stays closed unless a command was specifically classified as a network command and you approved it; with the optional egress proxy enabled, an approved command reaches only the hosts you allowlisted and nothing else.

• Filesystem: reads are open (so a build script finds its configs and caches) except the sensitive paths below; writes are confined to your workspace, temp space, and toolchain caches, with .git and project metadata kept read-only.
• Sensitive files: SSH, cloud, and package-manager credentials and .env files are off-limits even when the surrounding directory is readable.
• Network: closed by default; it opens only for a command explicitly recognized as a network command after you've approved it. With the optional egress proxy, an approved command's traffic is confined to an allowlist of hosts at the OS boundary.

Sandboxing by platform

On macOS and Linux the sandbox is enforced by the operating system: commands run inside an OS-enforced filesystem and network boundary, so the limits above are applied by the OS, not just checked beforehand.

On Windows the sandbox is tiered. By default Squeezy uses a restricted-token tier that needs no admin and is always available: each command runs under a restricted token whose write access is gated by per-workspace capability SIDs and on-disk ACLs, so the operating system enforces where the command can write. That default tier does not gate reads, and network isolation is not applied on it. An opt-in elevated tier, set up once behind a single permission prompt, runs commands as a dedicated sandbox user and adds full read isolation and network egress control. Either way, Squeezy reliably cleans up a command and all of its child processes.

When isolation is set to required

By default the sandbox is best-effort: Squeezy uses the OS boundary whenever the host can apply it, and if a machine refuses to set it up, the command still runs under the rest of the controls (permission policy, the environment allowlist, timeouts, and output limits).

If you'd rather never run a shell command without OS-enforced isolation, set the sandbox to required. In that mode, if the boundary can't be applied, on a locked-down host that won't allow it, or on Windows only when the sandbox is turned off or set to the elevated tier before its one-time setup has run, the command is refused before it starts rather than running with weaker protection. The default Windows tier satisfies required on its own.

Related

• Configuration
• How it works