Access
Permissions
Permissions are Swarm's tool-execution safety layer. They decide whether a tool call is allowed, denied, or paused for your approval. The current controls cover Bash commands, saved rules, subagent launches, session deployment, plan acceptance, protected changes, and a global bypass switch.
Every tool call resolves to allow, ask, or deny.
Swarm evaluates the current execution mode, built-in safeguards, dedicated capability policies, the saved
account policy, and the tool call itself. When the result is ask, Swarm creates a pending
permission and waits for a decision before the operation runs.
A prompt can be approved once or denied once. Supported prompts can also save an always-allow or always-deny rule. A saved rule is not proof that every future call with the same prefix or tool is safe; review broad rules and remove them when they are no longer needed.
Permissions are not provider authentication or a sandbox. Auth controls model credentials; permissions control tool execution. A permitted command still runs with the access available to the local Swarm service.
Bash approvals have three account-wide profiles.
Default
The shipped profile. It follows saved rules and existing defaults, and asks before Bash commands that
are not already allowed or denied. Built-in safe prefixes such as cd and ls can
still run without a prompt.
Allow every read
Automatically approves every command classified as a read, including critical reads. Writes, updates,
and deletes fall back to their normal rules; detected deletes still ask.
Only critical prompts
Automatically approves commands classified as noncritical reads, writes, or updates. It asks for
critical operations and every detected delete.
For the highest-risk environments, use Default and require a prompt for commands instead of trusting AI-selected categories or criticality.
Both the model metadata and backend heuristics can misclassify a long, compound, unusual, or obfuscated command. Allow every read is intentionally less safe: if a mutating command is mistaken for a read, it can be approved and executed without a human decision.
Each Bash request declares an effect type and criticality.
ReadObserves state without intending to change it. Routine source reads, listings, searches, status checks, and ordinary local logs are normally noncritical.WriteCreates new state, files, resources, or processes. This includes builds and starting processes.UpdateMutates existing state without removing it, such as editing a file or changing configuration.DeleteRemoves state. Delete requests must declare critical=true, and all three Bash profiles ask before a detected delete.CriticalMarks an operation that deserves special attention, including destructive or privileged work, sensitive reads, public listeners, network exposure, production data, or outbound transfer.Swarm validates the required command, explanation, category, and critical flag. Backend checks promote some obvious deletes and sensitive operations, correct some output redirects from read to write, and reject some read declarations that contradict recognized mutations. These checks are bounded heuristics, not complete shell analysis.
Permission settings are separated by operation type.
Global permissions
Turns ordinary tool approval prompts on or off for the daemon. Turning permissions off enables the global bypass described below; it does not disable separately enforced capability boundaries or deny safeguards.
Bash approvals
Selects one of the three profiles above. The profile is account-wide and remains saved while global permissions are off, but it does not prompt until normal permissions are turned back on.
Subagents
Controls delegation to Finder, Coder, and Designer. Direct mode disables delegation; Ask reviews every
wave; Bounded automatic permits a configured number of waves per parent run. A separate active-child
limit caps concurrency, an over-budget action asks or denies, and write isolation can be required.
Session deployment
Controls creation of durable sessions. Ask reviews every deployment, Always allow permits it, and
Bounded automatic permits a configured number per parent run before the selected ask-or-deny limit action.
Fresh accounts ask.
Plan acceptance
Controls acceptance of a validated structured plan. It can ask every time or always allow acceptance;
continuation behavior remains a per-plan choice. Fresh accounts ask.
Protected changes
Gives skill changes, session commits, session archives, and session unarchives separate persistent
identities. Each can ask every time, always allow, or always deny. A generic tool rule does not
automatically authorize these isolated operations.
Saved permission rules
Stores granular allow, ask, or deny decisions for a tool, Bash command prefix, or phrase. Deny rules take precedence over profile auto-approval.
Granular rules target tools, Bash prefixes, or phrases.
toolMatches one normalized tool or protected-operation identity.bash_prefixMatches the first executable or script name after supported wrappers. It is not full shell parsing, regex matching, or argument inspection.phraseMatches lowercased text in tool arguments. Phrase deny rules are checked before explicit allow or ask rules.
Rule decisions are allow, ask, or deny. Deny rules override Bash profile
auto-approvals. Profile safety prompts override allow rules, while an auto-approval profile can take
precedence over a saved ask rule for an operation the profile allows.
Shipped safeguards reduce risk without guaranteeing command safety.
Built-in hard denyRecursive rm commands targeting root, home, the current directory, the parent directory, or wildcard equivalents are denied before profile and allow-rule evaluation.Default deny phrasesThe default policy also includes deny phrases for rm -rf / and rm -rf /*.Delete promotionRecognized commands such as rm, rmdir, unlink, shred, find -delete, git clean, and destructive truncation are promoted to critical deletes.Critical promotionRecognized privileged, sensitive, networked, production-data, and system-path operations are promoted to critical.Execution-mode limitsPlan mode denies write and edit. Read execution denies write, edit, and Bash. Readwrite execution denies Bash.
Do not read these safeguards as “all dangerous rm -rf commands are impossible.” The hard deny
recognizes specific dangerous recursive targets, and the backend catches a bounded set of obvious command
forms. Shell composition is flexible: a long command or an unrecognized program can still have effects that
were not inferred. In sensitive environments, review every command and use operating-system isolation,
least privilege, backups, and separate production controls as additional boundaries.
/permissions off is a global trust switch.
Bypass persists as bypass_permissions in the startup configuration and automatically approves
ordinary operations whose decision would otherwise be ask. While permissions are off, Bash approval
profiles, saved ask rules, and protected-change Ask every time settings remain saved but do
not prompt. They resume when normal permissions are turned back on.
Permissions off does not mean every capability is set to always allow. Subagent launches and durable session deployments are evaluated before the general bypass, and plan acceptance keeps its own approval boundary. These operations can therefore still ask when their separate policy is set to ask, or when a bounded automatic limit uses ask as its over-limit action. Change those capability settings separately if you want different behavior.
Built-in execution-mode restrictions, dangerous recursive-delete checks, explicit deny rules, and denied capability decisions can still block an operation. Do not depend on those checks as a complete sandbox or command analyzer.
Keep global permissions on unless the environment is deliberately disposable and isolated. Turn prompts
back on with /permissions on when bypass is no longer needed.
TUI commands
/permissions/permissions on/permissions off/permissions reset