CUGA LogoCUGA AGENT
Build

Sandbox

Where generated code and agent skills run — native, local, E2B, and OpenSandbox.

Sandbox

Architecture: The sandbox is part of the Capability layer — isolated execution for generated Python and skill scripts (native, e2b, opensandbox). Pairs with Agent Skills.

When CUGA generates Python or runs skill scripts, code executes in a sandbox backend. Pick one in settings.toml or via CLI flags.

BackendWhen to use
nativeDefault for skills demo — fast, in-process
localLocal subprocess isolation
opensandboxRemote sandbox via llm-sandbox (cuga start demo --sandbox)
e2bCloud sandboxes — best isolation, no local deps

Configure in settings.toml:

[advanced_features]
enable_shell_tool = true           # required for most agent skills
opensandbox_sandbox = true         # Docker OpenSandbox; needs `uv sync --extra opensandbox`
sandbox_mode = "native"            # native | local | e2b | opensandbox

Turn skills on separately ([skills] enabled = true). sandbox_mode is an advanced_features key — putting it under [skills] has no effect.

Try skills with a sandbox:

cuga start demo_skills
# or
cuga start demo --sandbox

E2B cloud sandbox

E2B runs code in isolated cloud VMs. Good for production isolation when you do not want generated code on your machine.

Setup:

  1. Get an API key from e2b.dev/dashboard
  2. Install deps: uv sync --group e2b
  3. Add to .env: E2B_API_KEY=...
  4. Set sandbox_mode = "e2b" in settings

For registry access from E2B sandboxes you may need to expose your local registry (e.g. ngrok). See the agent repo’s E2B docs for the full wiring.

Agent skills copy SKILL.md scripts into /workspace/skills/ inside the sandbox. See Skills for the full flow.