Skip to main content
The sandbox command group creates and manages AgentKit sandbox tools, then uses sandbox sessions to run commands, invoke agents, transfer files, open web previews, or inject local model subscription credentials. It can also initialize Claude self-host sandbox projects and pass Tool information to env for Runtime creation. sandbox create and sandbox config accept All-in-one, Skill, CodeEnv, DevEnv, ArkClawEnv, HermesEnv, and Private as public tool types.
Most sandbox commands read the AgentKit control-plane region from .agentkit/sandbox.yaml or AGENTKIT_SANDBOX_REGION; sandbox dashboard also accepts --region for the local dashboard session. For TOS mounts, set AGENTKIT_SANDBOX_TOS_REGION; when it is omitted, the CLI infers the TOS region from the bucket or current cloud environment.
Session-oriented commands share the same tool and session selectors: -s, --session-id <id>, --sid <id> selects the user session id; --tool-id <id> selects a sandbox tool id; --tool-name <name> resolves by tool name; --tool-type <type> selects the tool type. If local config already stores tool-id, tool-name, tool-type, or session-id, commands use those defaults as described in each option table when the corresponding option is omitted. Tool selection usually resolves explicit CLI options first, then .agentkit/sandbox.yaml, AGENTKIT_SANDBOX_TOOL_ID, and local cache or a remote Ready tool. Whether a command may auto-create a tool or prompt for selection depends on that command’s behavior below. Configure control-plane credentials for the selected provider and confirm that the region supports the tool type. For BytePlus, use agentkit --provider byteplus and its matching region. Tools are not interchangeable across providers or regions A tool is a cloud compute resource; a session contains a separate file and process environment. Local session cache is only a locator and does not prove that the remote session is still active. Verify it with sandbox list --sessions --remote --tool-id <id>. Sessions have a TTL; disconnecting a terminal does not guarantee permanent file retention

Command overview

sandbox build

Build a custom sandbox image in cloud Code Pipeline. After a successful build, the CLI sets tool-type to Private and writes the generated image URL plus build state to .agentkit/sandbox.yaml for later sandbox create commands. If .agentkit/sandbox.yaml contains build config, sandbox build reads the build context, Dockerfile, image name, namespace, and tag from it; command-line flags take precedence over the config file.
sandbox build uses cloud resources such as TOS, Container Registry, and Code Pipeline, which may incur charges. Confirm account permissions, the project directory, and image naming before running it.
Build output shows current status and elapsed time. Failures retain logs and error details for diagnosis

sandbox init

Generate a sandbox Dockerfile template. When no template is specified, the command generates the skill template. Ordinary templates resolve the current built-in base image for the template’s tool type and write the concrete image URL into the generated Dockerfile. The self-host template initializes a Claude self-host sandbox project and writes Dockerfile, .gitignore, .dockerignore, README.md, and .agentkit/sandbox.yaml.
Except for self-host, resolving the built-in base image requires usable AgentKit control-plane credentials and region configuration. Offline or unauthorized environments cannot generate an ordinary template with a concrete base image.
The .agentkit/sandbox.yaml generated by the self-host template includes project_type: self-host, build config, Private Tool defaults, and the self_host config block. Before running agentkit env create, replace self_host.environment.environment_base_url, self_host.environment.environment_id, and self_host.environment.environment_key with the actual Anthropic environment settings; leaving generated placeholders in place makes creation fail.

sandbox config

Configure local defaults for sandbox commands. The config file is .agentkit/sandbox.yaml in the current project. --list prints the current config file and redacts model API keys, WebSearch API keys, and Claude self-host environment keys.
When .agentkit/sandbox.yaml is first written, the CLI persists only foundational defaults such as networking, tool type, CPU, snapshots, and session TTL. Model provider, model name, and model base URL are filled in when the effective config is read, and are persisted only after you set them explicitly with sandbox config --set model-* or command-line flags. Supported config keys are listed below.

Tool authentication and skill configuration

Model Environment Variables

Model options for sandbox create and sandbox exec are translated into multiple environment variable names so Codex, OpenCode, and runtimes or tools that read MODEL_AGENT_* can share the same settings. When --model-base-url points to a non-built-in model endpoint, pass --model-provider as well. For an existing CodeEnv session, model name, API key, or base URL values passed explicitly to sandbox exec update /home/gem/.env, Codex config, and OpenCode config inside the session, so later terminals reuse the same settings.
Generated Codex config is written to /home/gem/.codex/config.toml inside the sandbox session. General model options no longer generate ANTHROPIC_* variables and no longer pass generated config through CODEX_CONFIG_TOML or CODEX_MODEL_CATALOG_JSON; to customize Codex config, edit that file inside the session or run sandbox codex-login again to rewrite the subscription login config.

sandbox create

Create a sandbox tool. After creation, the CLI waits until the tool reaches Ready, then stores the tool id and name in local sandbox config. For projects with project_type: self-host, the result is written to self_host.sandbox.id and self_host.sandbox.name so env create can create the Runtime.
sandbox create provisions cloud compute resources that may incur charges while they exist. Confirm the tool type, resource size, network settings, image, and TOS mount configuration before creating one. Delete unused tools with sandbox delete --tool-id <id> --force.
When --network-private is enabled, the CLI reuses network-vpc-id and network-subnet-ids from the command line or .agentkit/sandbox.yaml when both are complete. If the config is incomplete, the CLI queries VPCs and available subnets in the current region, prompts for a selection, writes the result back to .agentkit/sandbox.yaml, and then continues creating the tool.
To enable LLM Shield for a Skill tool, pass the app ID explicitly. This option is supported only with Skill tool type.
To create a custom Private tool, prepare an image URL first:
Claude self-host sandboxes usually start from the sandbox init -t self-host project template, then build the configured image and create a Private Tool:

sandbox dashboard

Start a local web dashboard for viewing and operating sandbox tools and sessions. The command listens on a local port and opens a browser in an interactive terminal by default; in CI or with --no-open, it only prints the URL.
Standalone binaries installed through the install script or agentkit upgrade include the assets required by the dashboard terminal UI, so no extra Node.js dependencies are needed. When manually extracting a standalone release, keep the vendor/ directory beside ak in the same install directory; otherwise the dashboard page may not load the terminal component.

sandbox delete

Delete a sandbox tool or a specific session under a tool. When a session id is passed, the command deletes that session; when it is omitted, the command deletes the tool itself. Tool deletion must target exactly one tool with either --tool-id or --tool-name.
Deleting a sandbox tool or session cannot be undone. Files, runtime state, and session cache that were not persisted elsewhere may be lost. Confirm the target id or name and download required files before proceeding.

sandbox list

List sandbox sessions or tools and always print JSON. When neither --tools nor --sessions is passed, the command defaults to --sessions --local and reads the local session cache; with --tools, it reads the local tool cache by default. Pass --remote explicitly to query remote data.
sandbox list is an inspection command and does not auto-create or select a sandbox tool through the tool resolution chain used by session-oriented commands. --tools and --sessions are mutually exclusive, as are --local and --remote; --tool-name, --tool-type, and --status are valid only in tool mode.

sandbox mount

Open a TOS-mounted sandbox session directory in TosBrowser. The target tool must already have a TOS mount, and a login profile usable for mount authorization must exist locally through agentkit login.

sandbox exec

Connect to a sandbox terminal and execute a command. Use --command to provide the initial command after connection; omit it to open a terminal connection. --mode tmux attaches to or creates a tmux session named after the session id.

sandbox invoke

Invoke an agent in a sandbox through A2A. The default tool type is SkillEnv, and output is JSON. With --async, the command returns immediately after creating the task; with --task-id, it polls an existing task.

sandbox run

Read a YAML file and convert its entries into agentkit sandbox exec commands. The default file name is agentkit-sandbox-run.yaml. The root can be a list, or an object containing exec, execs, tabs, or commands.
agentkit-sandbox-run.yaml
Entry fields include session_id, sid, tool_id, tool_type, command, mode, shell_id, git_config, model_name, model_api_key, model_provider, model_base_url, cwd, workdir, copy, and copies. You can also use args or argv to provide the raw sandbox exec argument list directly.

sandbox shell

Run a non-interactive shell command in the sandbox and print the JSON result. This command requires --command and is suited to scripts; use sandbox exec when you need an interactive terminal.

sandbox web

Open the sandbox web preview and print JSON containing the URL, tool id, session id, and whether the session was newly created. When opening a browser by default, the CLI also asks the remote sandbox browser to open /home/gem/ so the session files are immediately visible; with --no-open, it only returns the web URL.
The command waits for the sandbox browser before opening its home page. The URL exposes the remote browser interface, not an arbitrary application port. Navigate to the service address inside that browser to inspect a web app running in the session

sandbox codex-login

Inject local Codex or Claude subscription credentials into a sandbox session. model-login is equivalent to this command.
sandbox codex-login and sandbox model-login copy local subscription credentials into a remote sandbox session. Use them only with a trusted sandbox and a dedicated session, and avoid sharing that session. Delete the session or sandbox tool when finished.
With --provider codex, the CLI writes /home/gem/.codex/config.toml inside the sandbox session, configures the codex_login model provider for OAuth login, and sets the default model gpt-5.5 through CODEX_MODEL, OPENCODE_MODEL, and MODEL_AGENT_NAME. Local API keys are not injected with subscription credentials.

sandbox model-login

model-login is equivalent to codex-login; it injects local Codex or Claude subscription credentials into a sandbox session.

sandbox scp

Transfer files or directories between local storage and an existing sandbox session. Remote paths must start with sandbox:; relative remote paths resolve under /home/gem. This command uses the local session cache, so create the target session first with sandbox exec, sandbox shell, sandbox web, sandbox invoke, or a login command.

Skill spaces, roles, and JWT

Creating a Skill tool requires either --role-name or --skill-role-name; they cannot be combined or repeated. Interactive selection lists roles and missing policies, disables roles that do not qualify, and can offer to create a default role. Non-interactive environments must provide a role name Other tools also require AgentKitTOSMountAccess when mounting TOS. Role options cannot be combined with --websearch-apikey. The CLI does not silently add missing policies to an existing role
Creating tools can incur cloud charges. If an explicitly supplied role name does not exist, the CLI automatically creates an IAM role and attaches the required policies. Interactive selection can also create a default role after confirmation. Creating roles requires the corresponding IAM permissions. Check the JWT discovery URL and allowed client IDs before granting access
--skill-space-id ss-example selects a space directly. Bare --skill-space-id confirms the value in .agentkit/sandbox.yaml or selects a space from the default project in an interactive terminal. Successful creation saves skill-space-id. Omitting this option does not inject a space ID automatically. JSON output and CI do not support interactive selection apikey rejects JWT-only options. Save settings through sandbox config --set auth-type=jwt and the jwt-discovery-url, allowed-clients, and skill-space-id keys. Explicit create options take precedence

Session snapshots

The tool must support snapshots; use --enable-snapshot when creating it. Check the snapshot status with get before resuming. Availability depends on the tool type and region. All snapshot subcommands require explicit --tool-id rather than inferring this mandatory option from ordinary session commands

sandbox snapshot create

Create a snapshot for a sandbox session Save tool_id from tool creation first. The examples below require an existing report-session session in that tool
--session-id resolves a user session within the tool. Use --instance-id when multiple instances match; it directly selects an instance and takes precedence. In results, session_id identifies the user session and instance_id identifies the instance Save the snapshot ID returned by creation, then inspect whether the snapshot is ready

sandbox snapshot get

Get a sandbox session snapshot

sandbox snapshot list

List sandbox session snapshots

sandbox snapshot resume

Resume a sandbox session from a snapshot
Resuming can create a billable instance or change session state on the original instance. Verify the snapshot and target tool first

sandbox snapshot delete

Delete a sandbox session snapshot
This command deletes the snapshot immediately, without a confirmation prompt or --yes. The deleted snapshot can no longer restore a session
Last modified on September 19, 2026