# Prepare a coding runtime

The coding worker runs in Docker. A separate execution image supplies the tools
available to repository commands. Use a non-root Linux operator with a local
rootful Docker engine, cgroup v2, and Docker's built-in seccomp profile.

Install the project dependencies with `uv sync`. Keep this installation and its
parent directories protected from writes by other users. The session checks the
installation before accepting work; it does not modify those permissions.

## Build and select images

From `coding/`, build the supplied Dockerfiles, then record the installed image IDs:

```sh
docker build -f operator/worker.Dockerfile -t chio-coding-worker .
docker build -f operator/execution.Dockerfile -t chio-coding-python .
uv run chio-mini-swe runtime-profile \
  --worker-image chio-coding-worker \
  --execution-image chio-coding-python \
  --helper-image python:3.11-slim \
  --out runtime.json
```

The profile command inspects installed images. It does not pull, build, or
implicitly update them. `runtime.json` records exact immutable IDs. The session
captures those identities at initialization; changing a tag later does not change
an existing session. Distribute that profile with the corresponding images.

The Dockerfiles use the normal package distribution. The existing `build-images.py`
is a separate release qualification tool for selecting local wheel artifacts and
recording their Dockerfile hashes. It is not a prerequisite of this application.

## Select a provider

Copy `operator/provider.example.json` to `provider.json`. Replace its endpoint,
model, and token prices with those of your selected provider. `credential_env`
names an environment variable; the JSON file must never contain the API key.
The example prices of zero are only placeholders. Set real prices for cost limits.

## Authorize a session

Session initialization writes `.session/provisioning-request.json`, which names
exact commands, tool manifests, and source identities. Review it and supply signed
launch policies for the model and repository services, plus independently pinned
signer keys. Save the resulting authorization document as `authorization.json`.
The request itself authorizes nothing.

For a trusted local test only, the supplied `authorize-demo.py` uses the native
local provisioning profile with no OS confinement:

```sh
uv run python authorize-demo.py .session/provisioning-request.json local-policies
uv run chio-mini-swe session prepare --state .session \
  --authorization local-policies/authorization.json
```

Production preparation uses your operator-signed policies instead. Ordinary run
and recovery never generate replacement policies for changed targets.