Skip to main content
Sandbox backends provide isolated command execution environments with explicit shell control to prevent injection attacks while enabling shell features when needed.
The user runs commands through the agent; the sandbox backend isolates execution with explicit shell control.
Sandbox backends now ship in a dedicated praisonai-sandbox package. If you use the agent-level API (sandbox=True, SandboxConfig), the existing from praisonai.sandbox import ... imports and praisonai extras continue to work — the standalone package is installed for you. Install praisonai-sandbox directly only when you want the sandbox stack without the full praisonai wrapper (e.g. embedding a sandbox in a small script or another project).
Package layout. Sandbox backends live in the standalone praisonai-sandbox package. pip install praisonai pulls it in transitively; you can also install it alone with pip install praisonai-sandbox when you don’t need the rest of the framework. All praisonai.sandbox.* imports keep working via a compatibility shim, so existing agent code does not need to change. See The praisonai-sandbox Package for details.

Quick Start

1

Simple Usage

Enable sandbox on the agent — subprocess backend is the default:
2

With Configuration

Pick a specific backend via SandboxConfig or the CLI --sandbox-type flag:

How It Works


Which Backend Should I Use?

Pick a backend based on where the code runs and how much you trust it.

All Built-in Sandbox Backends

PR #2003 exposes all seven sandboxes through SandboxRegistry — selectable by string name from the CLI or Python. Plugin-registered backends (installed separately, resolved via the praisonai.sandbox entry-point group):

Select by Name

Using the Daytona backend

Run agent code in a Daytona cloud sandbox by selecting the daytona backend.
Daytona requires pip install "praisonai[daytona]" (or pip install "praisonai-sandbox[daytona]") and a DAYTONA_API_KEY environment variable. Optional DAYTONA_API_URL and DAYTONA_TARGET env vars override the API endpoint and region.

Installing Optional Backends

Only subprocess and sandlock ship in the base install — every other backend requires an optional extra. The standalone praisonai-sandbox package is the preferred install; the legacy praisonai[...] extras still work as compatibility shims.
The daytona backend is now a real cloud provider (DaytonaSandbox) backed by daytona-sdk, mirroring the Modal / E2B compute-provider pattern. It lives in the standalone praisonai-sandbox package — install it via praisonai-sandbox[daytona]. Set DAYTONA_API_KEY (and optional DAYTONA_API_URL) before selecting it.
Selecting an uninstalled backend exits with code 2 and prints a fix-it hint — no silent downgrade to subprocess:
You’ll never get an unexpected backend — if --sandbox-type X isn’t available, the CLI tells you exactly what to install.
For plugin-registered backends (like capsule), SandboxManager resolves the name through SandboxRegistry and raises a clearer error when the plugin is missing. When praisonai is installed but the plugin is not registered:
When praisonai itself is not installed (the registry import fails):

Third-Party Sandbox Plugins

Register custom sandboxes via the praisonai.sandbox entry-point group:
After pip install, the new name appears alongside the built-ins when you call registry.list_names().

Example: Capsule (from praisonai-plugins)

The capsule backend is registered by praisonai-plugins under the praisonai.sandbox entry-point group. SandboxManager resolves the name via SandboxRegistry the first time the sandbox starts.

Using the standalone package

The seven backends live in a dedicated package so you can use them without pulling in the full praisonai wrapper.
Nothing to change — the standalone package is installed alongside praisonai:

Which Sandbox Should I Pick?


Configuration Options

Shell Parameter Control

Security: No shell injection possible. String commands are parsed with shlex.split().
Set shell=True only when you need shell features (pipes, &&, globbing). With untrusted input always keep shell=False.

Decision Guide


Common Patterns

Backend Selection

Safe Data Processing

Resource Limits


Best Practices

Model-generated commands or user input should never use shell=True to prevent injection attacks. The default shell=False provides automatic protection.
If you must use shell=True, quote all dynamic arguments with shlex.quote():
Using argument lists avoids shell parsing entirely:
Choose the sandbox backend based on your isolation requirements:
  • Development: SubprocessSandbox for speed and convenience (no longer inherits host environment)
  • Production: DockerSandbox for container-level isolation
  • Remote: SSHSandbox for network-isolated execution
  • High Security: Always use Docker or SSH backends with shell=False
Catch exit code 2 from praisonai sandbox run --type <X> and either install the extra or fall back to --sandbox-type subprocess:
In CI pipelines, install the required extra before running:

Sandbox

Agent-level sandbox=True and SandboxConfig

Sandbox CLI

CLI reference for praisonai sandbox run and praisonai sandbox shell

praisonai-sandbox Package

Standalone sandbox package — sandboxed execution without the full wrapper