Choose an Environment

Select a public environment provider and configure its complete environment-parameter schema.

Environments give benchmarks and harnesses one execution surface for commands, files, workspaces, endpoints, network policy, and resource cleanup. Select the provider with --env:

agentcompass run <benchmark> <harness> "$MODEL_NAME" --env <environment>

Environment List

The table uses the ids and descriptions registered for the public environment providers in the current AgentCompass checkout. Run the command after pulling new code to inspect the installed registry:

agentcompass list env

id	description
daytona	Start an isolated Daytona sandbox per task.
docker	Start an isolated Docker container per task.
host_process	Run directly in the local host process.
modal	Start an isolated Modal sandbox per task.

Choose host_process only for trusted local workloads that require no isolation. Use Docker for local containerized execution and Daytona or Modal when tasks must run in remote sandboxes. Each provider page documents prerequisites, credentials, supported resources, network capabilities, and operational limitations.

Configure Environment Parameters

The General Run Parameter Reference introduces --env-params <json>. The <json> value combines provider-neutral network controls with fields owned by the selected environment provider:

environment params
  ├─ shared setup, run, and verifier network policies
  └─ fields defined by the selected provider config

agentcompass run <benchmark> <harness> "$MODEL_NAME" \
  --env <environment> \
  --env-params '{
    "<provider-field>": "<value>",
    "run_network_policy": "no-network"
  }'

Shared Network Fields

These fields are extracted into EnvironmentSpec before the selected provider config is built:

Field	Type	Default	Protected phase
network_policy	policy string or object	"public"	Environment startup, benchmark preparation, and trusted harness setup
run_network_policy	policy string or object	Inherits network_policy	Agent or harness execution
verifier_network_policy	policy string or object	Inherits network_policy	Evaluation in a reused or fresh verifier environment

A policy string is one of "public", "no-network", or "allowlist". Use the object form when an allowlist is required:

{
  "network_mode": "allowlist",
  "allowed_hosts": ["api.example.com", "*.example.org", "203.0.113.10"]
}

The selected provider must be able to enforce every requested mode and allowlist entry. Docker, Daytona, and Modal can switch policies between phases; host_process supports only public. See Network Policy for provider-specific allowlist support and verification.

Selected Provider Fields

RuntimeEnvironmentConfig has no other shared user-facing fields. Each provider defines its complete schema according to its official runtime API:

Field family	Examples	What it controls
Authentication and scope	API keys, token id/secret, endpoint, organization, target	Connects AgentCompass to a remote provider account. Prefer environment-variable references for secrets.
Sandbox source	image, snapshot, named_image, platform	Selects the task runtime. Provider-native selectors may be mutually exclusive with registry images.
Workspace and process	workspace, workdir, default_workspace_root, command	Determines where commands run and which process keeps the environment active.
Resources	CPU, memory, GPU, disk/storage, placement, resources	Limits or places the environment according to provider-specific units.
Lifecycle	startup, operation, idle, maximum-lifetime, stop and deletion settings	Controls environment creation, operation, retention, and cleanup.
Files and environment	mounts, volumes, environment variables, labels, tags	Attaches data and provider metadata to the task environment.
Native network fields	Docker network, Modal CIDR/domain lists, Daytona network/domain lists	Exposes provider-native controls used alongside the provider-neutral policies.

Field names, units, defaults, and mutual exclusions differ between providers. Do not copy a Daytona resources object into Docker or assume Modal memory uses Docker size syntax.

See Sandbox Resource Limits for a provider comparison, exact units, precedence, capacity planning, and failure diagnosis.

Inspect the Complete Schema

Print every accepted provider field, type, default, and description from the installed implementation:

agentcompass config docs env <environment-id>

The corresponding provider page explains valid values, credentials, resource units, network behavior, and operational trade-offs that cannot be expressed by type and default alone.

Build the JSON Object

For example, a custom Docker run can combine Docker fields with the three phase policies:

{
  "image": "python:3.13-slim",
  "workspace": "/workspace",
  "cpus": 2,
  "memory": "6g",
  "memory_swap": "6g",
  "network_policy": "public",
  "run_network_policy": "no-network",
  "verifier_network_policy": "no-network"
}

This expanded object demonstrates ownership; it is not a recommendation to repeat defaults. Pass only intentional overrides. Heavyweight benchmarks usually provide task images, workspace roots, and resource hints in task metadata, and compatible recipes translate them for the selected provider.

Explicit compatible --env-params values take precedence over inferred recipe defaults. Preserve the benchmark’s official image, resource, and network settings when reproducing a public score; record every intentional difference.

--env-params must be valid JSON. CLI values deep-merge over matching keys in environment.params from configuration files. Inspect the merged built-in and configuration-file values before adding the final CLI override:

agentcompass config show \
  --env <environment-id> \
  --config <config-file>

Scale the Provider Safely

--task-concurrency controls tasks in flight, --provider-limit bounds process-wide provider sessions, and --env-open-qps paces environment creation. These are runtime parameters rather than --env-params fields. Use agentcompass run to tune them against model capacity, provider quota, and available CPU, memory, and storage.