# Decide what a step's sandbox is missing

When a step needs a tool or a service its sandbox does not have, it tells you, and you decide whether to add it. You get one approval per repository and step, however many runs hit the same gap. This page covers what that approval asks, what each answer does, and where to see the state of things.

## What you are asked

The step reports what it needs by name, with the command it ran and what that printed. The approval reads like this:

> The QA check step is missing the following from its environment: chromium, postgres.

Decide each item on its own.

- **Approve** it, and ampm files one task to add the approved items to `.ampm/environment.json` and its Dockerfile, with a check per item so every later run can tell it is there. The task starts at P1, or at P0 when a P0 task is waiting on the item, so the fix never queues behind the work it holds up. It is checked for duplicates and refined like any other task. When you accept its refinement it goes straight to planning, with no sprint plan and no sprint slot, and its history says why. Agents cannot lower it below P1; you still can. The rebuilt image still comes to you for approval before it is built. A task that could not continue without the item waits on the same approval. It carries on by itself once the rebuilt environment is in use, or as soon as you choose **Release waiting tasks now**.
- **Refuse** it, with a reason if you like. The step is told on every run that the item is not available and why, and works without it. Choose when you want to be asked again: in a week, a month, three months, or never. Refusing the same item again suggests a longer wait.

You can also give guidance for the whole step, such as "pin every version" or "keep the image small". The step is told it on every run, and it is copied into the task. The approval lists the other steps that share the image, because approving a tool for one step hands it to all of them unless the step has a [profile of its own](/docs/sandbox-environment#write-the-file).

Applying your choices saves the rulings, any environment task, guidance, and changes to waiting tasks together. If saving fails, none of those changes are kept. Releasing waiting tasks resumes their work without approving or refusing any undecided need.

Only you can make these decisions. Autopilot never answers them, and they cannot be delegated to an agent.

## Reports a check already answers

If a check's `provides` list already proved the item present in that run, the first report never reaches you. ampm tells the same run to start the item, using the check's `starter` if one is declared, and to finish its work. Only a report that recurs after that reminder is filed and held for your decision. The handled reports are still kept. The step's environment-needs page lists them in a collapsed line, apart from the rows waiting on a decision, with no approve or refuse control of their own.

## Environment variables

A missing environment variable appears on the same approval, by name only. Approving it files no task. You set the variable yourself under Settings → Repositories → Environment variables, or as a workspace default, and the tasks waiting on it continue as soon as it is saved. ampm never asks for, shows, logs or sends an agent a variable's value through this approval, and the step is told never to print one.

Settings lists a secret variable by name and delivery steps, without showing its value. Nonsecret configuration values remain visible. A lost save response retries in the same page; keep it open to retry. Reload sends nothing and loses that retry identity, so inspect the saved settings before submitting again.

Each variable says which steps receive it: every step (the default, and what every existing variable is), or only the steps you tick. Use **Change steps** on a variable to narrow or widen it, and the value is not asked for again. When you add a variable a step is waiting on, it is offered to that step alone unless you choose every step. A repository's own variable replaces a workspace default of the same name whole, steps included.

Refusing a variable tells the step to work without it. It is withheld only when the step is not among the variable's steps, and the decisions list tells you when a refused step still receives it.

## See what was decided and what runs today

Every decision is listed under the repository in Settings → Repositories → Environment decisions, with **Ask again** to reopen one.

Beside it, **Environment** shows what the repository runs in today: each profile with the steps it serves, its image, the checks it declares and what each returned on the newest run, plus every revision of the environment with the one in use marked. Look there first when a step reports something missing. A check that passed means the tool is in the image and did not start. A profile with no check for the tool confirms nothing about it.

## When a check you declared fails

An image that fails one of the checks you declared is put to you the same way. The failed check appears on the step's approval by its name, every task that ran into it waits there, and they resume together once a fixed image is approved and in use.