Skip to main content
Environments

Environment schemas

Environment object and configuration structures.

Environment object

Returned by create, get, list, update, and archive endpoints.
FieldTypeDescription
idstringEnvironment ID with the env_ prefix
typestringAlways "environment"
namestringEnvironment name
descriptionstringEnvironment description
configEnvironment configEnvironment configuration
metadataobjectMetadata object. Defaults to {}
archived_atstring | nullArchive time in UTC, or null when not archived
created_atstringCreation time in UTC
updated_atstringLast update time in UTC

Environment config

FieldTypeRequiredDescription
typestringYes"cloud" or "self_hosted"
packagesEnvironment packagesNoPackage declarations associated with the environment
setup_scriptstringNoUser setup script text. See Environment setup script
startup_scriptstringNoScript run on every start of the sandbox. See Environment startup script
storageEnvironment storageNoMounts of your own OSS buckets; cloud config only
For self_hosted, the config can contain type and an optional setup_script and startup_script:
{"type": "self_hosted", "setup_script": "./initialize-worker.sh"}
A 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 [].
KeyTypeDescriptionExample
typestringAlways "packages" in responses"packages"
aptarray of stringDebian/Ubuntu system package declarations["git", "curl", "build-essential"]
npmarray of stringNode.js package declarations["typescript@5.0.0", "eslint"]
piparray of stringPython package declarations["pandas", "PyYAML==6.0.1"]
cargoarray of stringReserved response field; package installation through this field is not currently supported[]
gemarray of stringReserved response field; package installation through this field is not currently supported[]
goarray of stringReserved 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.
ConstraintValue
Typestring
Max length64 KB
Interpreter/bin/bash -lc
Timeout10 minutes
When it runsSandbox preparation, after packages installation
On success a completion marker is written inside the sandbox so the script does not run twice in the same sandbox; when the sandbox is recreated, the script runs again. A non-zero exit aborts session startup. The error response includes the setup_script exit code and a stderr excerpt to help diagnose the failure.
{
  "config": {
    "type": "cloud",
    "setup_script": "set -euo pipefail\n[ -d /data/workspace/repo/.git ] || git clone https://github.com/me/repo /data/workspace/repo\ncd /data/workspace/repo && pnpm install --frozen-lockfile"
  }
}

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_scriptstartup_script
RunsOnce per sandboxOnce on every start of the sandbox (the first start and each resume)
Use forInstalling dependencies, cloning repositories, warming cachesStarting services and background processes
ConstraintValue
Typestring
Max length64 KB
Interpreter/bin/bash -lc, with the same working directory and environment variables as setup_script
Timeout5 minutes
When it runsAfter each start of the sandbox, before the first tool runs; on the first start, after setup_script
When writing the 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 with pgrep -f for 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 with pgrep -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.
A failed script does not fail the session, and the sandbox stays usable. Each start in which the script fails produces one 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.
{
  "config": {
    "type": "cloud",
    "packages": {"apt": ["redis-server"]},
    "startup_script": "pgrep -x redis-server || redis-server --daemonize yes\ncurl -s -o /dev/null localhost:3000 || (cd /data/workspace/repo && nohup pnpm dev > /tmp/dev.log 2>&1 &)"
  }
}

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).
FieldTypeRequiredDescription
namestringYesMount directory name; unique within the Environment
providerstringYesAlways "aliyun-oss"
regionstringYesOSS region ID, for example cn-hangzhou
bucketstringYesBucket name
prefixstringNoMount only this prefix; omitted means the whole bucket
accessstringNoread_only (default) or read_write
accelerator_endpointstringNo<label>.oss-data-acc.aliyuncs.com
credentialobjectYes{"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.
{
  "type": "cloud",
  "storage": {
    "buckets": [
      {
        "name": "datasets",
        "provider": "aliyun-oss",
        "region": "cn-hangzhou",
        "bucket": "my-bucket",
        "prefix": "team/data/",
        "access": "read_only",
        "credential": {"type": "ram_role", "role_arn": "acs:ram::1234567890123456:role/qoder-oss-mount"}
      }
    ]
  }
}