Agent Sandbox Registry

agent-sandbox

Decision: BYO agent integration — dedicated templates + custom_commands contract, no in-SDK agent runtime

无中文版

.agents/notes/implemented/architecture/2026-09-29-byo-agent-integration-contract.md

Decision: BYO agent integration — dedicated templates + custom_commands contract, no in-SDK agent runtime

Status: implemented Proposed: 2026-09-29 Implemented: 2026-09-29 Related: 2026-09-29-pluggable-coding-agent-backend.md, 2026-09-29-template-catalog-single-source-of-truth.md, 2026-09-29-skills-design-removal-and-mcp-docs-convergence.md

Problem

Task 195 evaluated whether Agent Sandbox should ship a pluggable sandbox-embedded agent (e.g. a bundled Qwen Code CLI) instead of leaving agents to the user. The evaluation covered Qwen Code CLI, Qoder CLI, Codex CLI, Claude Code, and user-defined agent commands: install channels, real headless CLI behaviour, runtime and system dependencies, auth modes, licenses, image size, startup cost, version locking, security boundaries, and network/credential requirements.

Two integration axes were being conflated in the docs:

  1. Host-side generation — abx create "<description>" runs Qwen Code on the host to generate Dockerfile + template.yaml (already covered by the pluggable-backend ADR; Qwen Code is the default host backend).
  2. In-sandbox agents — a coding-agent CLI running inside the sandbox to do the actual work.

Without an explicit decision, the pressure was to (a) preinstall every agent into the default base image, (b) add an agent capability / SDK orchestration layer duplicating agent planning loops, (c) download agents on first sandbox run, or (d) redistribute proprietary binaries (Claude Code, Qoder CLI) in official templates. Each option fails a licensing, reliability, or layering constraint.

Decision

Bring Your Own Agent (BYO). Agent Sandbox provides the isolated runtime and the operational surface; the agent CLI provides planning, reasoning, code generation, and its tool loop. Concretely:

Responsibility split

Packaging: dedicated templates, not the base image

The minimal contract = existing custom_commands

No new capability, template schema, or SDK API. A BYO agent template maps the contract onto the CustomCommand model that already exists (src/agent_sandbox/models/template.py):

Contract element Mechanism
Install / probe Dockerfile build-time install + a probe command (agent_probe)
Headless startup custom_commands.<name>.cmd with {placeholder} tokens
Prompt input required args[] entry (filled after shlex.quote())
JSON output flags in cmd; format documented in description; stdout parsed by the caller
Auth env whitelist env names in template.yaml + values via abx create --env
Working directory custom_commands.<name>.cwd (/workspace convention)
Timeout custom_commands.<name>.timeout per turn; sandbox TTL separate
Resource limits resources.cpu / resources.memory; Sandbox.create(cpu=, memory=) overrides
Lifecycle abx create --timeout, abx kill <id>
Error mapping non-zero exit code + stderr on CommandResult
Version locking exact versions in the Dockerfile (+ SHA256 for archives)
License boundary official (Apache-2.0) vs proprietary (BYO/community only)

Per-CLI dialects are preserved (Codex uses codex exec --json; the rest use -p; permission/output flags differ) — templates adapt to the CLI, the contract does not force uniformity.

Docs and verification

API Design

N/A — this decision does not involve API changes. The contract reuses the existing CustomCommand / custom_commands mechanism and the existing CLI (abx run <id> <name>) and SDK (sandbox.custom(name, **kwargs)) entry points.

Alternatives considered

Dependencies

None new. Documentation and tests only; no SDK, CLI, or template-schema changes. The contract depends on the existing custom_commands model and the existing template pipeline.

Test Strategy

Acceptance criteria

Consequences

Evidence

Files changed