Description
nemoclaw onboard --non-interactive --agent hermes intermittently fails during Hermes sandbox creation with the strict base-image acceptance error below. This has been observed while running the Hermes agent for a VSS blueprint from a notebook with NemoClaw v0.0.74, v0.0.80, and v0.0.81.
Unlike the original v0.0.74 regression, the rejected digest in the v0.0.80/v0.0.81 recurrence is the official hermes-sandbox-base:v0.0.80 release-tag OCI index, not Docker's platform-normalized child digest. This indicates that base-image resolution reached a release-tag/override result that the final Hermes trust guard cannot accept.
Command
cd ~ && nemoclaw onboard --non-interactive --agent hermes
Actual result
Error: Hermes final image does not accept base image ref 'ghcr.io/nvidia/nemoclaw/hermes-sandbox-base@sha256:7e9378c50f291e6dd80b922e8b89e0e7edf21e4e3a80b8c2664be01976f59aa8'; use the tracked official digest or a repository-built local base
Sandbox creation aborts.
Expected result
The resolver should either:
- continue using the Dockerfile-tracked immutable Hermes base, including an official platform digest with pinned provenance; or
- stop with the underlying pull/runtime-validation error.
It should not select an official release-tag candidate that the final Hermes guard will necessarily reject.
Findings
Why this may be intermittent
The exception alone does not establish which path triggered the fallback. Plausible causes are:
- a transient pull or 20-second Hermes MCP/runtime probe failure for the tracked pin, followed by release-tag fallback;
- a stale recorded base-image resolution hint;
- a notebook/VSS environment value such as
NEMOCLAW_HERMES_SANDBOX_BASE_IMAGE_REF, NEMOCLAW_SANDBOX_BASE_VERSION_TAG, NEMOCLAW_INSTALL_REF, or NEMOCLAW_INSTALL_TAG=v0.0.80; or
- mixed installed-source state.
The identical 7e9378... digest after moving from v0.0.80 to v0.0.81 makes stale v0.0.80 identity/metadata especially worth checking.
Safe workaround
Leave the explicit Hermes override unset, bypass recorded resolution metadata, and retry:
unset NEMOCLAW_HERMES_SANDBOX_BASE_IMAGE_REF
NEMOCLAW_SANDBOX_BASE_IMAGE_REFRESH=1 nemoclaw onboard --non-interactive --agent hermes
If necessary, pre-pull the Dockerfile-tracked pin before retrying, while keeping the override unset:
docker pull ghcr.io/nvidia/nemoclaw/hermes-sandbox-base@sha256:fa05221f5c7bcafea7e263c84e5d06f87e37d1ccb78dc28c113f1a4066aa544c
Do not set 7e9378... as the Hermes override: it is an official release-tag image, but it is not the immutable base trusted by the v0.0.80/v0.0.81 final Hermes Dockerfile.
Suggested diagnostics
which nemoclaw
nemoclaw --version
env | grep -E '^NEMOCLAW_(HERMES_SANDBOX_BASE_IMAGE_REF|SANDBOX_BASE_VERSION_TAG|INSTALL_REF|INSTALL_TAG)='
Please also capture the base-image resolver output immediately before the exception.
Related
Description
nemoclaw onboard --non-interactive --agent hermesintermittently fails during Hermes sandbox creation with the strict base-image acceptance error below. This has been observed while running the Hermes agent for a VSS blueprint from a notebook with NemoClaw v0.0.74, v0.0.80, and v0.0.81.Unlike the original v0.0.74 regression, the rejected digest in the v0.0.80/v0.0.81 recurrence is the official
hermes-sandbox-base:v0.0.80release-tag OCI index, not Docker's platform-normalized child digest. This indicates that base-image resolution reached a release-tag/override result that the final Hermes trust guard cannot accept.Command
Actual result
Sandbox creation aborts.
Expected result
The resolver should either:
It should not select an official release-tag candidate that the final Hermes guard will necessarily reject.
Findings
sha256:7e9378c50f...is the OCI index behindghcr.io/nvidia/nemoclaw/hermes-sandbox-base:v0.0.80:sha256:21764ac48a936b4783dc345be093a5be4adb5e573123c0dd3e094c8862f3b862sha256:7ab5b4c9b256d1cf087ba326722f772400724c0aa02ce90f2cb883bddbe0c783agents/hermes/Dockerfile:sha256:fa05221f5c7bcafea7e263c84e5d06f87e37d1ccb78dc28c113f1a4066aa544csha256:2446c27100c8f1bf633ae8385fbc154d42fad0ce3e5b26bf834000503cefefa8sha256:68debdbe149c4506be8c1d1c2906f593bab5567cc470945a6e6e7f4c5047b177source: pinnedand a matchingpinnedRemoteRef.7e9378...is valid and official, but aversion-tagor explicit-override result using it is rejected by design. The apparent bug is the resolver/guard seam that allows this unacceptable fallback result to reach final-image validation.Why this may be intermittent
The exception alone does not establish which path triggered the fallback. Plausible causes are:
NEMOCLAW_HERMES_SANDBOX_BASE_IMAGE_REF,NEMOCLAW_SANDBOX_BASE_VERSION_TAG,NEMOCLAW_INSTALL_REF, orNEMOCLAW_INSTALL_TAG=v0.0.80; orThe identical
7e9378...digest after moving from v0.0.80 to v0.0.81 makes stale v0.0.80 identity/metadata especially worth checking.Safe workaround
Leave the explicit Hermes override unset, bypass recorded resolution metadata, and retry:
unset NEMOCLAW_HERMES_SANDBOX_BASE_IMAGE_REF NEMOCLAW_SANDBOX_BASE_IMAGE_REFRESH=1 nemoclaw onboard --non-interactive --agent hermesIf necessary, pre-pull the Dockerfile-tracked pin before retrying, while keeping the override unset:
Do not set
7e9378...as the Hermes override: it is an official release-tag image, but it is not the immutable base trusted by the v0.0.80/v0.0.81 final Hermes Dockerfile.Suggested diagnostics
Please also capture the base-image resolver output immediately before the exception.
Related