Permissions & safety

Choose how much the agent does on its own

Access controls which requests need consent. Change it from /modes, or set permissions.access in a durable settings scope. Mode independently selects Chat, Plan, Build or Orchestrate; an Access choice does not switch Mode.

The built-in Access ring uses Ask, Auto and Full, spelled ask, auto and full in permissions.access. custom uses hand-tuned capabilities; { profile = "name" } selects an Access profile. Selecting Full through the TUI or CLI requires permissions.full_access_available = true or SQUEEZY_FULL_ACCESS_AVAILABLE=1. This switch controls selection, not an explicitly authored permissions.access = "full" policy. Project settings cannot supply the availability switch or grant themselves wider authority.

• Ask (ask in settings): normal workspace reads, searches, edits, shell, builds, tests and git use the configured permission rules. Web and MCP calls, browser or computer control, destructive operations and writes outside the workspace can require your approval.
• Auto (auto in settings): permits ordinary workspace work and routine web access under the configured rules. Eligible exact approval effects go to the approval reviewer; effects without Reviewer authority come directly to you.
• Full (full in settings): skips ordinary consent cards and does not call the approval reviewer. Explicit ask and deny rules remain effective, and the configured sandbox and transport restrictions still apply.
• Custom access uses [permissions.custom]. Named Access profiles under [access_profiles.<name>] hold capabilities and reviewer choices; select one with permissions.access = { profile = "name" }. Profiles preserve the current Mode and do not add a working posture or a rung to the Mode cycle.

When a decision still reaches you

Ask routes unmatched external, structural, network, MCP, and destructive effects to you. A custom policy follows the capability values and rules you chose. In Auto, an exact Allow/Once effect goes to the reviewer only when that effect grants Reviewer authority; otherwise it comes directly to you. An explicit ask rule also comes to you, and an explicit deny remains terminal.

Full is a separate consent axis: it does not call the reviewer and ordinarily proceeds without a card. It does not disable confinement, so the shell sandbox and transport boundaries still apply exactly as configured.

• Risk ratings and hazard tags are context, not automatic reviewer vetoes. In Auto, a Reviewer-authorized exact effect may cover browser or computer control, hooks and protected metadata, bounded structural, path, sandbox, or environment changes, and destructive work whose loss stays inside the repository.
• Secret disclosure or export, raw clipboard disclosure, sending file bytes to an external destination, irreversible external mutation, destruction outside the repository, and a dynamic MCP operation with no locally audited read-only or reversible contract omit Reviewer authority. Ask and Auto send those exact effects to you without paying for an AI review.
• Approving one exact command, path, origin, or target does not approve a different one. A wider standing answer is offered only when the producer can prove a truthful recurring subject.

When Squeezy asks, what you can answer

An approval prompt names the tool, the exact target, and the reason it stopped. You can approve or refuse this one call, or record the answer so the same call does not ask again: for this session only, for this project, or everywhere. Both directions are offered, so a refusal can be made durable too.

A project answer is stored on your machine, in this project's own entry under Squeezy's home directory, never inside the repository. Approving something for yourself cannot commit that approval into a checkout your teammates share.

You do not have to wait for a prompt to learn what the policy would say. squeezy permissions check evaluates a call against your merged settings and prints the decision, every rule that matched and which one won, the safety floors that applied, and, for a shell command, the sandbox it would run under.

squeezy permissions check shell -- rm -rf build
squeezy permissions check edit --target 'path:src/main.rs'
squeezy permissions check web --target 'domain:example.test' --json

How the approval reviewer decides

Auto uses the approval reviewer for exact effects that grant it authority. The reviewer considers the proposed effect, recent conversation and its configured policy. Set its Base model, policy, extra instructions, timeout and transcript budget through permissions.approval_reviewer or the Modes & Access page. An explicit ask rule still reaches you directly.

Its default remit includes every capability family, though you may configure a narrower set. It receives one exact Allow/Once effect and can clear it only when that effect grants Reviewer authority. Browser and computer control, hooks and protected metadata, bounded structural hazards, and repository-local destructive work can all qualify. A critical rating or hazard tag informs the review; neither removes authority on its own.

Effects that disclose or export secrets, expose raw clipboard contents, send file bytes to an external destination, mutate an external system irreversibly, destroy data outside the repository, or call a dynamic MCP operation without a locally audited read-only or reversible contract omit Reviewer authority. Built-in MCP resource, list, prompt, and completion operations retain their exact checked authority. Auto skips the reviewer for ineligible effects and asks you directly. Full remains separate: it does not use the reviewer and settles ordinary consent on its own axis.

Run /reviewer to see every card and its single disposition: cleared, escalated, or skipped with the reason. A reviewer Allow counts as cleared only after the exact effect revalidates and applies.

Plan mode: explore freely, change nothing

Plan mode is a different axis from the setting above. It is the goal of the session rather than the trust level, and you switch into it with /plan and back with /build. The common idea that it only allows reading and searching is too narrow: Plan mode draws its line at changing things, not at running them, so a plan can rest on evidence instead of guesses.

While it is active the file-editing tools are not offered to the model at all, and an attempt to use one is refused. Browser control, computer control, and destructive actions are refused the same way. Work that only observes runs on the normal permission path: reads, searches, read-only shell, read-only git such as status, diff, log, and show, and checks or builds that write nothing but their own caches and artifacts.

Every shell command is read before it runs. One that provably changes something is refused, and the refusal names the exact segment that tripped it, so a compound command tells you which half to drop. One that is neither provably read-only nor provably mutating is not waved through; it arrives as an ordinary approval prompt. Ask for the plan to be implemented from inside Plan mode and nothing is edited: you are told to switch to Build mode first.

• Allowed without asking: read, search, read-only shell and git, and checks or builds Squeezy can prove write only their own output, for example cargo check, cargo build, cargo test, cargo clippy, and cargo fmt --check.
• Refused outright: file edits, applying patches, formatters and code generation, browser and computer control, and any shell command proven to mutate, even one you would otherwise have permission to run.
• Sent to you: a command that cannot be proven either way.

The sandbox: what an allowed command can touch

Permissions decide whether a command starts. An active OS sandbox then enforces its configured boundary, including for commands you approved. The platform and sandbox mode determine which restrictions are available; best-effort can fall back without OS confinement, while required refuses that fallback.

Inside it, a command reads what ordinary work needs: the system tools, its own configuration, your project. It writes in your workspace, in the temporary directories, and in the per-user caches that cargo, npm, pnpm, go, gradle, maven and the rest need in order to build at all. It cannot write into .git, .squeezy, or .agents: that metadata is held read-only, so nothing rewrites the repository's own bookkeeping, or the agent's, without an approval that names it.

What it cannot read are your secrets. SSH keys, cloud and package-manager credentials, password stores, and .env files are blocked, including the .env sitting in the project being built, and so is Squeezy's own store of provider keys. The command also starts with an emptied environment: only a named list of ordinary variables is passed through, PATH, HOME, TERM, the toolchain and locale settings and their like, so an API key exported in your shell never reaches it.

The network stays closed unless the command is one Squeezy recognizes as making a network call, and whether such a command runs at all is a separate permission decision. On macOS and Linux there is an optional egress proxy: turn it on and an allowed command reaches only the domains you list, enforced at the operating system boundary rather than taken on trust.

Sandboxing by platform

On macOS and Linux the operating system applies the boundary itself, so the limits above are enforced while the command runs, not only checked before it starts.

Windows has two tiers. The default one needs no administrator and is always available: each command runs under a restricted token whose write access is gated by a capability SID for each writable root, plus the matching entries on disk, so Windows decides where the command may write. That tier gates writes only. It does not isolate reads and it does not block the network. The elevated tier adds both. It is provisioned once with squeezy doctor --sandbox-setup, which asks Windows for administrator approval, and afterwards each command runs as a dedicated hidden sandbox user with network egress filters attached.

On every platform, when a command finishes or is cancelled, Squeezy tears down the whole process tree it started rather than leaving orphans behind.

best-effort by default, required when you need it

The sandbox ships as best-effort: Squeezy applies the operating system boundary wherever the host allows it, and where a host refuses, the command still runs under everything else, the permission policy, the environment allowlist, the time limit, and the output limit.

If you would rather never run a shell command without that boundary, set the sandbox mode to required. A command that cannot be fully confined is then refused before it starts instead of running with less protection. A scripted run can demand the same thing on the command line, with --shell-sandbox required.

On Windows, required means the elevated tier, because the default tier isolates writes only and so cannot deliver the read and network confinement that required asks for.

Related

• Configuration
• Browser & computer use
• How it works