Problem
NemoClaw release tags pin the source checkout, but the sandbox base image is effectively floating.
Today .github/workflows/base-image.yaml publishes:
ghcr.io/nvidia/nemoclaw/sandbox-base:latest from main- short-SHA tags
It does not publish release/version tags such as v0.0.49, and release installers do not record a release-specific base digest.
That means installing an older release tag after main has moved can build the tagged Dockerfile on top of a newer sandbox-base:latest. This can break old installers when their Dockerfile patch logic assumes the OpenClaw/base shape that existed when the release was cut.
Recent example: openshell-gateway-upgrade-e2e attempted to create a v0.0.36 install as the old side of a v0.0.36 -> v0.0.49 upgrade test. The old installer resolved the current sandbox base containing OpenClaw 2026.5.18, then failed in rcf_patch.py because the compiled OpenClaw replaceConfigFile shape had drifted.
Proposal
Add release-stable base-image resolution so release installs are reproducible. Possible designs:
- Publish versioned base-image tags from
.github/workflows/base-image.yaml, e.g.
ghcr.io/nvidia/nemoclaw/sandbox-base:v0.0.49ghcr.io/nvidia/nemoclaw/hermes-sandbox-base:v0.0.49
- Or record the base image digest used for each release and make installers prefer that digest when installing a release tag.
- Or both: publish version tags and record the digest in release metadata/artifacts for auditability.
Acceptance criteria
- Installing a release tag uses a deterministic sandbox base ref/digest associated with that release.
- The base-image workflow supports release/version tagging or an equivalent release digest artifact.
- Upgrade E2Es can explicitly model historical release installs without depending on the mutable current
sandbox-base:latest.
- Documentation explains how release tags, short-SHA base tags, and
latest interact.
Context
Current behavior is source-version pinned but base-image floating. That is useful for freshness, but it makes old-release upgrade tests and user installs sensitive to unrelated future base changes.
Problem
NemoClaw release tags pin the source checkout, but the sandbox base image is effectively floating.
Today
.github/workflows/base-image.yamlpublishes:ghcr.io/nvidia/nemoclaw/sandbox-base:latestfrommainIt does not publish release/version tags such as
v0.0.49, and release installers do not record a release-specific base digest.That means installing an older release tag after
mainhas moved can build the tagged Dockerfile on top of a newersandbox-base:latest. This can break old installers when their Dockerfile patch logic assumes the OpenClaw/base shape that existed when the release was cut.Recent example:
openshell-gateway-upgrade-e2eattempted to create av0.0.36install as the old side of av0.0.36 -> v0.0.49upgrade test. The old installer resolved the current sandbox base containing OpenClaw2026.5.18, then failed inrcf_patch.pybecause the compiled OpenClawreplaceConfigFileshape had drifted.Proposal
Add release-stable base-image resolution so release installs are reproducible. Possible designs:
.github/workflows/base-image.yaml, e.g.ghcr.io/nvidia/nemoclaw/sandbox-base:v0.0.49ghcr.io/nvidia/nemoclaw/hermes-sandbox-base:v0.0.49Acceptance criteria
sandbox-base:latest.latestinteract.Context
Current behavior is source-version pinned but base-image floating. That is useful for freshness, but it makes old-release upgrade tests and user installs sensitive to unrelated future base changes.