Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Sandbox

Swarmie sandbox config lives under [sandbox] in config.toml (crates/core/src/config/toml_types.rs) and is resolved into SandboxConfig (crates/core/src/config/types.rs).

Config Shape

[sandbox]
allowed_paths = ["src/**", "docs/**"]
denied_paths = ["src/secrets/**", ".git/**"]
allowed_domains = ["api.example.com", "*.internal.local"]
FieldTypeDescription
allowed_pathsarray(string)Glob-like path patterns allowed for filesystem access.
denied_pathsarray(string)Explicit deny patterns applied on top of allow rules.
allowed_domainsarray(string)Domain allowlist value carried in config.

What It Enforces Today

Filesystem sandbox checks are applied in tool execution (crates/core/src/turn/tool_execution.rs) and file mention resolution (crates/core/src/mention.rs):

  • Read/write targets from tools like Read, Write, Edit, Patch, Glob, and Grep are validated.
  • @file mention expansion is validated before file content is injected into prompt context.

Denied access returns user-visible errors such as Filesystem sandbox denied ....

Rule Semantics

  • If [sandbox] is absent: policy defaults to working-directory scope.
  • If [sandbox] exists but allowed_paths is empty: policy still falls back to working-directory scope.
  • Invalid path patterns are ignored with warnings.

Notes on allowed_domains

allowed_domains is part of resolved config shape, but filesystem sandbox enforcement in turn/tool_execution.rs and mention.rs is path-focused. Domain enforcement is tool/runtime-specific.