Agent Sandbox Registry

agent-sandbox

Decision: abx deploy is the fixed publish step; descriptions belong to template authoring

无中文版

.agents/notes/implemented/feature/2026-09-30-deploy-fixed-pipeline-agent-flag.md

Decision: abx deploy is the fixed publish step; descriptions belong to template authoring

Status: implemented Implemented: 2026-09-30 Supersedes (partial): 2026-09-09-template-deploy-command.md — its "coexisting abx deploy" section (project deployment into a sandbox via an in-sandbox agent) is replaced. Related: 2026-09-30-nl-template-server-entrypoint.md, 2026-09-30-nl-template-init-and-create-scope-prompt.md.

The file name keeps agent-flag for history: a deploy --agent flag was first implemented and then withdrawn the same day (see "Reversed decision").

Problem

Reported while using the CLI:

  1. abx deploy failed with [E7001] No LLM API key found for qwen-code agent — asking for BAILIAN_CODING_PLAN_API_KEY / DASHSCOPE_API_KEY / OPENAI_API_KEY, unrelated to the LLM key abx config / abx create manage.
  2. abx deploy --verbose failed with No such option: --verbose.
  3. The intent was unclear: deploy is naturally "build + push + create template", a fixed procedure, yet it started a qwen-code cloud sandbox with its own agent and its own LLM route.

Root cause: deploy_shortcut was a separate "NL project deployment" product (Sandbox.deploy) that shared only the name with the template pipeline: its own credential chain (api/deploy.py), a private option set (no -v, no --region, no ACR options), unusable without an LLM.

Decision

The template lifecycle has three steps with one job each:

Step Command Input AI
1. Author abx template init / abx template init "DESCRIPTION" scaffold case or description → Dockerfile, commands.py, template.yaml optional
2. Publish abx deploy [PATH] the template directory never
3. Launch abx create --template ID template ID never

abx create "DESCRIPTION" = 1 + 2 + 3 with a confirmation before anything is pushed.

  1. abx deploy [PATH] = abx template deploy with PATH defaulting to .: docker build → push to ACR → CreateTemplate → poll. No LLM, no key, no cloud sandbox, no description argument. The option set is derived from template build.params at import time, so -v/--verbose, --acr-namespace, --region, --yes, ... are inherited and cannot drift.
  2. What a template is lives in template.yaml (plus Dockerfile / commands.py), written at authoring time. deploy only reads name, resources.cpu, resources.memory, generation; CLI options override them.
  3. A missing Dockerfile stops deploy with a message that points at abx template init.
  4. --traditional becomes a hidden, deprecated no-op with a warning. The old INSTRUCTION argument is removed (click reports an unexpected extra argument).
  5. Sandbox.deploy() (in-sandbox agent deploy) is kept as an SDK API only; DeployLLMKeyMissingError (E7001) remains for it, with an updated suggestion.

Reversed decision: deploy --agent

First implemented: abx deploy [PATH] [INSTRUCTION] --agent ran the local Qwen Code on the project to write Dockerfile + template.yaml before the pipeline (flag name chosen over --auto / --ai because it names the actor). It was withdrawn after review, for these reasons:

The code written for it (deploy --agent, CodingAgentBackend.generate_for_project, codegen.prepare_project_template, .abx-bak backups, tree fingerprinting) was removed rather than left as dead code.

Open follow-up (not implemented): adopting an existing project

An existing project without a Dockerfile / template.yaml has no AI path today. If needed, it belongs under authoring, not deploy: e.g. abx template init reading an existing directory and writing the template files next to the code, through the same _generate_template_workspace and TEMPLATE_GUIDE, with the backup / "files touched" guard rails that were prototyped here. It needs its own design because template init DIRECTORY currently means "scaffold into this directory" and natural-language init takes a single positional.

Alternatives rejected

Consequences

Verification