Known issue: runtime image pins pi-coding-agent@latest (unpinned upstream version)

[1openwindow]

Decision

Dockerfile.runtime installs @earendil-works/pi-coding-agent@latest instead of
an exact version pin.

RUN ... && npm install -g @earendil-works/pi-coding-agent@latest --ignore-scripts ...

Why this is a known tradeoff

Using @latest keeps the runtime in sync with upstream pi without manual bumps,
but it means each release build may pull a new, untested pi version:

• Not byte-reproducible: the same Dockerfile.runtime can produce different
  pi versions on different build dates.
• Passive upgrades: an upstream pi release (RPC protocol, model catalog, or
  CLI args) is pulled into the next build without an explicit review step.
• A versioned image tag (e.g. :0.3.1) therefore does not uniquely identify
  the pi version inside it.

Why it still works in CI today

.github/workflows/runtime-image.yml builds on ephemeral ubuntu-latest runners
with no cache-from / cache-to configured, so the
npm install -g ...@latest layer is rebuilt fresh on every run and genuinely
pulls the current latest. No cache-bust ARG or --no-cache is required for
release builds.

Note: local docker build reuses the buildx layer cache and may keep an older
pi version; add --no-cache locally to force a refresh.

Related

• Relevant to Reuse pi's built-in model catalog instead of hardcoded Foundry model capabilities #1: model-catalog work should be validated against the pi version
  actually present in the runtime image, which is now floating.

Status

Accepted tradeoff — documented here so it is discoverable rather than silent.