Skip to main content
E2BSandbox and DaytonaSandbox implement CloudSandbox. Their toolkit wrappers expose run, shell, read-file, and write-file tools. SDK loading and resource creation are lazy.

Install the selected adapter

Set the selected provider’s API key in server configuration. Provider isolation and network policy depend on your account/session configuration; the adapter does not create a universal network restriction.

Own and close the session

E2B uses the interpreter SDK’s default template. Its lifetime is separate from each operation’s timeout. Daytona language is fixed when the sandbox is created; create separate adapters for Python and Node. Daytona workspace selects an optional sandbox name, and baseURL maps to the SDK’s apiUrl.

Attach tools to an Agent

E2BSandboxToolkit and DaytonaSandboxToolkit expose getTools(), getSandbox(), and close(). Supply their tools to an Agent, then close the Agent and toolkit when the host finishes using them. Toolkit run/shell operations forward the execution context signal.

Lifecycle and limits

Concurrent starts create one sandbox. Close waits for pending SDK work, deletes owned sandboxes once, and is terminal. A borrowed Daytona client remains host-owned; its created sandboxes are adapter-owned. Nonzero exits and code errors remain failures. Only provider-specific file-not-found responses become null; authentication, network, and missing-sandbox failures reject. Returned output defaults to a 1 MiB bound, configurable up to 16 MiB. The SDK may buffer more internally; this is not a provider memory quota. Cancellation and client timeouts do not prove remote code stopped. Some provider calls cannot be aborted remotely. Do not automatically replay uncertain external effects. Ambiguous creation failures may need inspection in the provider account before retrying. See SandboxAgent for an explicit workspace wrapper and execution policy for tool controls.