Skip to main content
The agent runtime runs the pi coding agent (@mariozechner/pi-coding-agent) inside an isol8 container. Instead of executing code, it executes a prompt — pi handles the LLM loop, tool calls (read, write, edit, bash), and file edits autonomously, entirely within the sandbox.

Quick start

How it works

When runtime: "agent" is used, isol8 runs:
  • --no-session — disables session persistence (ephemeral, non-interactive). This is always set by isol8; you do not need to include it in agentFlags.
  • --append-system-prompt — automatically injected by isol8 to inform pi of sandbox constraints
  • agentFlags — extra pi flags you supply (model, thinking level, tool restrictions)
  • -p '<code>' — your prompt, shell-quoted
pi then runs its own tool-call loop inside the container. It can read, write, and edit files under /sandbox, and run arbitrary bash commands — all within the sandbox’s resource and network limits.
The isol8:agent Docker image (which provides bun, pi, and gh) is built automatically when you run isol8 setup or when DockerIsol8 first uses the agent runtime. If you need to build it manually — for example in an offline environment — run:

Networking requirement

The agent runtime requires network access — the AI coding agent must reach its LLM provider API. network: "none" throws:
Two valid network modes for the agent runtime:

Sandbox system prompt

Every pi invocation inside isol8 receives an automatically appended system prompt informing the agent that it is running in a sandbox with restricted network access and an ephemeral filesystem. This uses pi’s --append-system-prompt — it appends to pi’s default prompt without replacing it. You do not need to supply this yourself.

The code field

For the agent runtime, code is always the prompt text — never a script. It is passed to pi via -p '<prompt>' after shell-quoting.

Agent flags (agentFlags)

Use agentFlags (library/API) or --agent-flags (CLI) to pass extra arguments to pi before the -p flag.

Useful pi flags

Injecting files

Use files in ExecutionRequest (library/API) or --files <dir> (CLI) to inject local files into /sandbox before the agent runs.
pi automatically loads AGENTS.md (and CLAUDE.md) from the working directory at startup. Injecting your project rules as /sandbox/AGENTS.md gives the agent project-specific context without touching the prompt.

Setup scripts

A setupScript runs as a bash script inside the container before pi receives its prompt. Use it to clone repos, write config files, install tools, or prepare any state the agent needs. The script runs as the sandbox user from /sandbox.

Clone a repo before the agent starts

The most common pattern: clone the target repo so pi finds it ready on the filesystem.

Inject .npmrc or .gitconfig before the agent runs

The agent may need authenticated access to npm or private git remotes. Write config files via the setup script so credentials are in place before pi starts:

Inject AGENTS.md via setup script

pi auto-loads AGENTS.md from its working directory. Write project rules via the setup script to give the agent context without touching the prompt:

Bake setup into a custom image

For setup that never changes between runs (git identity, tool config, registry auth), bake it into a custom image using prebuiltImages[].setupScript in your config. The script runs on every execution against that image without adding per-request latency:
isol8.config.json
Then your execution only needs the per-run parts:
When both image-level and request-level setupScript are set, the image-level script always runs first. See Setup scripts for the full reference.

Persistent sessions

Use mode: "persistent" to run multiple steps in the same container — for example, cloning a repo with bash and then running the agent against it:

Streaming agent output

pi produces output incrementally. Use executeStream to receive it in real-time:
Each event carries an optional phase field ("setup" or "code") so you can distinguish setup-script output from agent output:
If the setupScript exits non-zero, the stream yields a { type: "error", phase: "setup" } event followed by an exit event, and the agent never starts. Filter on phase to surface setup failures separately from agent failures.

Default resource limits

The agent runtime spawns subprocesses for tool calls (bash, package installs, git operations). The default pidsLimit of 64 is often too low — explicitly set pidsLimit: 200 to avoid process limit errors:

Retrieving output files

Use outputPaths to include files written by the agent in the result:
Or retrieve files explicitly with getFile() after execution in a persistent session.

LLM API key handling

Pass the API key via engine secrets (recommended — masked from output) or per-request env:

Troubleshooting

Error: Agent runtime requires network access — Switch to network: "filtered" with at least one whitelist entry, or network: "host". network: "none" is not supported for the agent runtime. Agent exits non-zero — Check result.stderr. Common causes: missing API key, endpoint not in whitelist, timeoutMs too short. Agent can’t reach the LLM API — Verify the whitelist pattern. Patterns are matched as extended regular expressions using grep -E (substring match, not full-string). Without anchors, a pattern like anthropic\\.com would also match evil-anthropic.com.attacker.net. Use ^ and $ anchors for precise matching: ^api\\.anthropic\\.com$. Files not in result — Add outputPaths or call getFile() after the run. In ephemeral mode, container state is discarded on exit.

One-shot coding agents

Architecture and pipeline: clone repo, implement, verify, fix, and open a PR — with no human in the loop.

Setup scripts

Full reference for setupScript: image-level vs request-level, execution order, error handling.

AI agent code execution

Foundational patterns for LLM tool-call loops with isol8.

Runtime reference

All six runtimes: commands, extensions, package install behavior.

Security model

Network controls, seccomp, secret masking, and isolation boundaries.