Skip to main content

Sandbox runs: test a pipeline change before it lands

Changing a recipe is risky when every attempt updates your repo's required check and blocks merge on your branch. Sandbox runs let an agent test an inline recipe in isolation before that recipe touches your branch protection gate.

Legend: sandbox verdicts never touch your repo's required check — only the promoted PR does.

How it works​

  1. An agent calls slipstream_run_sandbox with an inline recipe for a specific commit.
  2. The sandbox run executes in isolation on an executor and posts no check to your repo.
  3. If it is no longer wanted, slipstream_cancel confirms first — naming the repo and run id it is about to kill — and only then records a terminal cancellation and stops the exact executor run; CI and deploy runs cannot use this surface.
  4. On green, the agent calls slipstream_recipe_promote, which opens a normal PR with the recipe change.
  5. That PR goes through the normal CI gate like any other change.

On red, the agent iterates the inline recipe and re-runs the sandbox until the stages pass. Your repo never sees the failed attempts — only the final promoted PR posts a check.

Why this matters for agents​

Agents can converge on a working recipe without burning red checks on the repo. Each sandbox run uses an inline recipe that does not change .slipstream.json until you promote. The promoted change still lands through the same reviewable PR gate as code, so branch protection and human review apply before the recipe becomes canonical. All sandbox and promote operations run through the MCP server.