Workbench

Run coding work in an isolated factory

Workbench gives an agent a repository, an isolated development box, and a test gate. It keeps iterating on the requested change until the gate passes, then opens a pull request.

Use it for bounded engineering work with an objective success condition: a test command, lint check, build, or repository-owned validation script.

How a run works

  1. workbench_clone creates or selects a box and clones the repository.
  2. workbench_attempt gives the coding agent the task, then runs the gate inside the repository's declared container.
  3. The workflow can repeat the attempt with the gate output as feedback.
  4. workbench_submit pushes the result, opens a pull request, and releases a leased cloud box.

The coding agent runs on the box. The gate always runs in a container declared by the target repository; Workbench never falls back to running an unknown project directly on the host.

Before the first run

  • Prepare the repository with a devcontainer, Dockerfile, or Compose test service.
  • Choose a gate that exits 0 only when the result is acceptable.
  • For parallel or ephemeral runs, choose a cloud box provider.
  • Keep generated files and build output in .gitignore so they do not enter the pull request.

For environment variables and exact tool inputs, see the .

Next

On this page