fabro/docs/administration/sandboxing.mdx
Bryan Helmkamp 84195a183f
Remove SSH and Exe sandbox providers
Only three sandbox providers remain: Local, Docker, and Daytona.

- Move detect_clone_params and GitCloneParams from ssh_common into daytona module
- Delete ssh/, exe/, and ssh_common.rs implementation files
- Remove Exe/Ssh variants from SandboxProvider, SandboxSpec, CliSandboxProvider
- Remove data_host from Sandbox trait and SandboxRecord
- Remove ExeSettings, SshSettings, ExeConfig, SshConfig types
- Remove ssh/exe/exedev feature flags from all Cargo.toml files
- Remove openssh workspace dependency
- Remove ExeSettings/SshSettings from OpenAPI spec
- Update docs to remove SSH/Exe references, delete exe-dev.mdx

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-30 12:17:20 -04:00

16 lines
1.1 KiB
Text

---
title: "Sandboxing"
description: "Sandboxing workflow execution"
---
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 supports three sandbox providers: `local` (no isolation), `docker` (container-level), and `daytona` (cloud VM). See [Environments](/execution/environments) for full provider-specific configuration.
## Network access control
For cloud sandboxes (Daytona), you can control outbound network access with the `network` field in `[sandbox.daytona]`. Three modes are available: `"allow_all"` (default), `"block"`, and `{ allow_list = ["..."] }` for CIDR-based egress filtering.
Server defaults in `server.toml` apply when a run config doesn't specify `network`. Individual run configs can override the server default.
See [Environments — Network access](/execution/environments#network-access) for syntax examples and the full reference.