> ## Documentation Index
> Fetch the complete documentation index at: https://docs.eigenpal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Agent sandboxes

> Enable filesystem tools for agents or disable the sandbox capability.

EigenPal agents need a sandbox when they use filesystem tools or skills. Agents without a filesystem can run without one. Workflow `transform.script` steps use QuickJS independently.

## Enable agents

Agents keep their source in a Git server, which the Helm chart does not install. The chart therefore disables agents (`agents.enabled: false`): the Agents area is hidden, agent API calls return not found and agent runs are refused. Workflows are unaffected.

To enable agents, operate a Git server, then set `agents.enabled: true` and supply `AGENT_GIT_BASE_URL` and `AGENT_GIT_ADMIN_TOKEN` to app and worker through `extraEnv`. Outside the chart, `EIGENPAL_AGENTS_ENABLED` defaults to true.

## Disable agent filesystem sandboxes

Set this on both app and worker, then restart them:

```yaml theme={null}
app:
  extraEnv:
    - name: EIGENPAL_SANDBOX_ENABLED
      value: 'false'
worker:
  extraEnv:
    - name: EIGENPAL_SANDBOX_ENABLED
      value: 'false'
```

Filesystem-dependent agents fail with a capability error. Existing sandbox cleanup remains available. To disable workflow scripts too, set `SCRIPT_ENABLED=false` on the worker.

## Enable a backend

The core Helm chart does not install a sandbox runtime or agent Git server. Configure the Git server through `AGENT_GIT_BASE_URL`, persistent repository storage and matching operator credentials. Use the [runtime reference](https://docs.eigenpal.com/self-hosting/environment-variables.md#agent-sandboxes) for process settings.

> [accordion] E2B
>
> Set `SANDBOX_PROVIDER=e2b`, `E2B_API_KEY` and a release-compatible `E2B_SANDBOX_TEMPLATE` on app and worker. Pin a template supplied for your release; the unset-template fallback is intended for development.

> [accordion] Docker
>
> Set `SANDBOX_PROVIDER=docker` and `DOCKER_SANDBOX_IMAGE`. Use `DOCKER_SANDBOX_PLATFORM` if needed. Supply a Docker daemon accessible to the processes that manage sandboxes. The default image is local-only; use a release-compatible image.
>
> A Docker socket gives substantial control over its host. Isolate this runtime from general application workloads.

> [accordion] Remote runtime
>
> Set `SANDBOX_PROVIDER=remote`, `SANDBOX_REMOTE_URL` and `SANDBOX_REMOTE_AUTH_TOKEN` on app and worker. Provision the remote sidecar separately and set its `SIDECAR_AUTH_TOKEN` to the same secret of at least 32 characters. The sidecar must support authenticated session leases. Use remote runtimes only with single-tenant installations. Keep the service private and protect the connection with TLS. A shared sidecar does not provide a fresh OS boundary for each session; use per-run containers or VMs for stronger isolation.

## Builder requirements

The interactive builder and training sessions still use E2B, including when inference uses Docker or remote. Configure a callback address reachable from the sandbox through `EIGENPAL_API_BASE_URL` and the required relays.

> [!WARNING]
>
> Builder storage mounts require a working AWS STS or R2 scoped credential issuer. Mounts fail when
> scoped credentials cannot be issued.

> [accordion] Scoped storage credentials
>
> Use `sandboxStorage.stsRoleArn` with permission to assume the role, or configure `sandboxStorage.r2AccountId` and `r2ApiTokenSecret`. Credential lifetimes default to 3600 seconds and accept 900 to 43200 when supported by the issuer. AWS role chaining limits sessions to 3600 seconds. Mounts refuse to start when the scoped credential issuer is unavailable.
>
> This storage-mount path belongs to the builder. Inference sandboxes use a separate file-transfer path.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.