Skip to main content
Use this workflow before applying an agent whose inline environment changes its base image, build steps, or setup commands. It gives a repository agent a plain-Docker preflight for the current debian-contract-v0 hosted runtime contract; it does not apply a resource or create a hosted sandbox.

Choose the authored image

An inline environment accepts either an auto-managed preset or one direct Docker/OCI base-image reference:
The direct form accepts one image-reference token. Whitespace, comments, continuations, and option-looking values are rejected. auto inserts the reference into a generated, single-stage FROM instruction; it does not import a repository Dockerfile or upload a Docker build context as environment configuration. Mutable tags can drift: a later build of debian:bookworm can resolve to different bytes even when the .auto file did not change. auto currently preserves the authored reference rather than resolving and persisting its digest. Pin ref to a registry digest when reproducible rebuilds matter.

Debian contract v0

A direct base image must satisfy every hard requirement below. The hosted build then runs in this order: base image, USER root, compatibility probe, auto’s harness bootstrap, your environment.steps, workspace-user creation, git mount, and your environment.setup commands as the non-root workspace user. A base without /bin/sh can fail before the probe can print a classified line. The current bootstrap also uses apt-get to install its base tools, including git, so a nominally glibc-compatible non-Debian image is not enough.

Run the local preflight

1

Copy the authored sequence

Read the agent and any imported environment fragments first. Record the resolved image.ref, copy each environment.steps entry in order, copy each environment.setup[].commands entry in order, and identify the repository’s existing smoke commands. Do not write a compiler or translator for .auto; this is a reviewed transcription of the environment you are about to apply.
2

Create a disposable source export

Run from the repository root after committing the environment change you intend to apply. The quoted heredoc reads the image ref as data, so shell metacharacters in a reviewed file are never evaluated by the host shell. Replace only its one data line.
The Docker context now contains only files committed at HEAD: no .git directory, ignored file, untracked .env, or untracked .npmrc can enter the image or Docker build cache. If the relevant changes are not committed, stop and commit them before continuing; the export deliberately ignores the live working tree.
3

Create a temporary validation Dockerfile

Create the file at $validation_dockerfile, using the template below. Keep the compatibility-probe line byte-for-byte intact. Replace only the marked authored step and setup examples with the commands from the repository.
Dockerfile
The local COPY and final RUN model the hosted mount-then-setup order. They do not reproduce the auto harness packages or E2B’s setup snapshot cache, so this remains a compatibility and repository-command preflight rather than proof of a hosted template build.
4

Build and run the known-good case

Ask Docker to parse and pull the ref first, then build and run both legs explicitly as linux/amd64. Docker’s own reference parser rejects values outside canonical Docker/OCI reference grammar; a parse or pull failure stops the preflight. Keep the variable expansions quoted exactly as shown and replace the smoke command with the repository’s real checks.
A pass proves the selected base can execute the compatibility path, the authored build and setup commands succeed in the right order and user context, and the repository’s chosen smoke checks pass inside the resulting image.
5

Prove the incompatible classification

Run the same Dockerfile and clean export against Alpine. alpine:3.23 is a deterministic negative fixture for this contract because it uses musl rather than glibc.
The marker is classified as an image_build failure: the image violates debian-contract-v0, so retrying it as provider infrastructure trouble would not help.
6

Clean up the local artifacts

Author the inline environment

After the local preflight passes, put the environment directly on an agent or in an imported agent fragment. Standalone .auto/environments/ files are invalid.
.auto/agents/repository-agent.yaml
Keep repository tests in their normal CI as well; the local image check adds a platform-compatibility leg but does not replace repository CI.

Run the hosted preflight

In a hosted auto sandbox, validate the committed .auto working tree through the local Auto MCP tool before apply:
Focused agent file
Use auto.resources.dry_run({}) when you want full-directory, prune-aware validation. Both forms are read-only: they parse, validate, and plan the resource set, but they do not apply it and do not execute a production E2B template build. A clean dry-run therefore proves the hosted authoring surface accepts the exact image shape; it does not replace the local Docker preflight or a later real session through the hosted provider.

Environment reference

Field constraints for images, build steps, setup, caches, resources, and approvals.

GitHub Sync

How committed .auto changes are validated and applied after merge.