mirror of
https://github.com/fabro-sh/fabro.git
synced 2026-09-07 08:27:12 +00:00
157ec03a18
Reflect Docker as the default sandbox provider, add `skip_clone` for clone-based providers, document the `[run.sandbox.docker]` config table, and update tutorial command lines from `files-internal/...` to `docs/internal/...`. Bump the docs skill watermark to the latest synced commit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
16 lines
1.1 KiB
Text
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 `[run.sandbox.daytona]`. Three modes are available: `"allow_all"` (default), `"block"`, and `{ allow_list = ["..."] }` for CIDR-based egress filtering.
|
|
|
|
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](/execution/environments#network-access) for syntax examples and the full reference.
|