Environment object and configuration structures.
Environment object
Returned by create, get, list, update, and archive endpoints.
| Field | Type | Description |
|---|---|---|
id | string | Environment ID with the env_ prefix |
type | string | Always "environment" |
name | string | Environment name |
description | string | Environment description |
config | Environment config | Environment configuration |
metadata | object | Metadata object. Defaults to {} |
archived_at | string | null | Archive time in UTC, or null when not archived |
created_at | string | Creation time in UTC |
updated_at | string | Last update time in UTC |
Environment config
| Field | Type | Required | Description |
|---|---|---|---|
type | string | Yes | "cloud" or "self_hosted" |
packages | Environment packages | No | Package declarations associated with the environment |
setup_script | string | No | User setup script text. See Environment setup script |
startup_script | string | No | Script run on every start of the sandbox. See Environment startup script |
storage | Environment storage | No | Mounts of your own OSS buckets; cloud config only |
self_hosted, the config can contain type and an optional setup_script and startup_script:
self_hosted config supports only type and an optional setup_script and startup_script. For self_hosted, startup_script is only stored and returned as is; whether to run it is up to the external worker.
Environment packages
packages maps package managers to arrays of package spec strings. Requests support apt, npm, and pip. Cloud Environment responses also contain several reserved fields; omitted arrays are returned as [].
| Key | Type | Description | Example |
|---|---|---|---|
type | string | Always "packages" in responses | "packages" |
apt | array of string | Debian/Ubuntu system package declarations | ["git", "curl", "build-essential"] |
npm | array of string | Node.js package declarations | ["typescript@5.0.0", "eslint"] |
pip | array of string | Python package declarations | ["pandas", "PyYAML==6.0.1"] |
cargo | array of string | Reserved response field; package installation through this field is not currently supported | [] |
gem | array of string | Reserved response field; package installation through this field is not currently supported | [] |
go | array of string | Reserved response field; package installation through this field is not currently supported | [] |
Environment setup script
setup_script is a shell script executed during sandbox preparation, after packages are installed. It runs through /bin/bash -lc. Use it for initialization steps that cannot be expressed as packages, for example, cloning a repository, writing config files, or warming caches.
| Constraint | Value |
|---|---|
| Type | string |
| Max length | 64 KB |
| Interpreter | /bin/bash -lc |
| Timeout | 10 minutes |
| When it runs | Sandbox preparation, after packages installation |
setup_script exit code and a stderr excerpt to help diagnose the failure.
Environment startup script
startup_script is a shell script run on every start of the sandbox: on its first start it runs after setup_script, and it runs again each time the sandbox resumes from a pause. Use it to start processes that do not survive a pause, such as databases, dev servers, and other background services.
When a sandbox is paused and resumed, the files on its disk are kept but its processes are not. Put steps whose results live on disk (installing dependencies, cloning repositories, warming caches) in setup_script, and starting processes in startup_script.
setup_script | startup_script | |
|---|---|---|
| Runs | Once per sandbox | Once on every start of the sandbox (the first start and each resume) |
| Use for | Installing dependencies, cloning repositories, warming caches | Starting services and background processes |
| Constraint | Value |
|---|---|
| Type | string |
| Max length | 64 KB |
| Interpreter | /bin/bash -lc, with the same working directory and environment variables as setup_script |
| Timeout | 5 minutes |
| When it runs | After each start of the sandbox, before the first tool runs; on the first start, after setup_script |
- The script must exit. Run long-lived processes in the background with their output redirected to a file, for example
nohup pnpm dev > /tmp/dev.log 2>&1 &; they keep running after the script exits. A command that runs in the foreground and never exits blocks tool calls until the timeout. - The script exiting does not mean the service is ready: the agent's first tool call starts as soon as the script exits, while a service started in the background may take a few seconds to listen. When the agent needs a service right away, wait for its port at the end of the script before exiting, for example
for i in $(seq 30); do curl -sf -o /dev/null localhost:3000 && break; sleep 1; done. - At the timeout, the script is stopped together with the background processes it started, and the run counts as failed.
- On a resume, processes from before may still be running (some runtimes keep memory across a pause), so the script must handle a service that is already running, for example
pgrep -x redis-server || redis-server --daemonize yes. Do not check withpgrep -ffor text that also appears in the script: the shell running the script carries the script's text in its command line and matches, so the service is never started; match the process name withpgrep -x, or check the service's port. - It runs at most once per start: the run is recorded before the script starts, so a run cut short is not repeated in the same start; it runs again on the next start.
session.error with error.type environment_startup_failed_error; its message carries the exit code and the end of the output, and the agent is told about the failure too. It is not retried within the same start.
Environment storage
storage.buckets[] declares your own OSS buckets to mount at /mnt/buckets/<name> in the sandbox. It is supported only in cloud configs and accepts at most 8 buckets. For credentials, authorization, permissions, and sandbox behavior, see Mount your own OSS buckets (Beta).
| Field | Type | Required | Description |
|---|---|---|---|
name | string | Yes | Mount directory name; unique within the Environment |
provider | string | Yes | Always "aliyun-oss" |
region | string | Yes | OSS region ID, for example cn-hangzhou |
bucket | string | Yes | Bucket name |
prefix | string | No | Mount only this prefix; omitted means the whole bucket |
access | string | No | read_only (default) or read_write |
accelerator_endpoint | string | No | <label>.oss-data-acc.aliyuncs.com |
credential | object | Yes | {"type":"ram_role","role_arn":"..."} or {"type":"access_key","access_key_id":"...","access_key_secret":"..."} |
credential is write-only: responses return only type; for access_key they also return a masked access_key_id (such as LTAI****sKey). Omitting the field on update, or echoing the masked value, keeps the stored credential.