Skip to main content
Sandboxes isolate agent execution from the host machine. When an agent runs a shell command, edits a file, or searches code, it does so inside a sandbox — preventing unintended side effects on the host and providing a reproducible environment for each run. Fabro bundles three sandbox providers: local (no isolation), docker (container-level), and daytona (cloud VM). Additional providers run as sandbox-driver plugins configured under [server.sandbox.providers.<kind>]; an environment selects one by its kind name. See Environments for full provider-specific configuration and Server configuration for plugin settings. Operators can enable or disable which providers the server may launch with [server.sandbox.providers.<kind>] in settings.toml. Missing bundled entries default to enabled = true; setting enabled = false rejects new runs whose effective provider is disabled, and a plugin kind with no entry is disabled. Dry-run runs on any non-local provider execute locally, so they are governed by the local provider policy. The API can also list Fabro-managed sandboxes directly from configured providers:
Provider-backed inventory is useful when you need to inspect Docker or Daytona resources independent of a single run projection. Listing is fail-soft: available provider results are returned with provider errors in response metadata.

​
Network access control

For cloud sandboxes (Daytona), you can control outbound network access with [environments.<slug>.network]. Three modes are available: "allow_all" (default), "block", and "cidr_allow_list" with an allow = ["..."] CIDR list. Server defaults in settings.toml apply when a run config doesn’t specify network. Individual run configs can override the server default. See Environments — Network access for syntax examples and the full reference.