nemohermes onboard --from agents/hermes/Dockerfile fails because the staged Docker build context doesn't match the Dockerfile

[rt266]

Investigation Summary

Environment

NemoHermes

nemohermes v0.0.83

Hermes
``
Hermes Agent v0.18.0 (2026.7.1)
Python 3.13.5

OS

Ubuntu Linux

GPU

NVIDIA GB10
Goal

I wanted to customize the Hermes sandbox by adding a few additional Python packages (for example firecrawl-py) using the documented --from workflow.

Command

From the repository root:

cd ~/ai/nemoclaw/NemoClaw

nemohermes onboard
--name gx10-hermes
--recreate-sandbox
--from agents/hermes/Dockerfile
Expected behavior

I expected the official Hermes Dockerfile to build successfully, allowing me to make small modifications (adding Python packages) and rebuild the sandbox.

The documentation states that --from builds the sandbox image from a custom Dockerfile and that the parent directory of the Dockerfile is used as the Docker build context.

Actual behavior

Build fails almost immediately:

COPY agents/hermes/plugin/ /opt/nemoclaw-hermes-plugin/

COPY failed:
file not found in build context or excluded by .dockerignore

stat agents/hermes/plugin/: file does not exist
Docker build context

During onboarding NemoClaw prints:

Using custom Dockerfile:
/home/ravi/ai/nemoclaw/NemoClaw/agents/hermes/Dockerfile

Docker build context:
/home/ravi/ai/nemoclaw/NemoClaw/agents/hermes

So the build context is:

agents/hermes/
However, the Dockerfile contains
COPY agents/hermes/plugin/ /opt/nemoclaw-hermes-plugin/
COPY agents/hermes/generate-config.ts /opt/nemoclaw-hermes-config/generate-config.ts
COPY agents/hermes/config/ /opt/nemoclaw-hermes-config/config/
COPY agents/hermes/host/managed-tool-gateway-matrix.json /opt/nemoclaw-hermes-config/managed-tool-gateway-matrix.json

COPY src/lib/tool-disclosure.ts /src/lib/tool-disclosure.ts
COPY src/lib/messaging/ /src/lib/messaging/

COPY scripts/lib/reviewed-npm-archive.mts /scripts/lib/reviewed-npm-archive.mts
COPY scripts/lib/sandbox-init.sh /usr/local/lib/nemoclaw/sandbox-init.sh
COPY scripts/lib/gateway-supervisor.sh /usr/local/lib/nemoclaw/gateway-supervisor.sh
COPY scripts/lib/sandbox-rlimits.sh /usr/local/lib/nemoclaw/sandbox-rlimits.sh

COPY nemoclaw-blueprint/ /opt/nemoclaw-blueprint/

COPY agents/hermes/start.sh /usr/local/bin/nemoclaw-start
COPY scripts/gateway-control.sh /usr/local/bin/nemoclaw-gateway-control
COPY scripts/managed-gateway-control.py /usr/local/lib/nemoclaw/managed-gateway-control.py

COPY agents/hermes/validate-env-secret-boundary.py /usr/local/lib/nemoclaw/validate-hermes-env-secret-boundary.py
COPY agents/hermes/patch-session-list-preview.py /usr/local/lib/nemoclaw/patch-hermes-session-list-preview.py
COPY agents/hermes/seed-dashboard-config.py /usr/local/lib/nemoclaw/seed-hermes-dashboard-config.py
COPY agents/hermes/runtime-config-guard.py /usr/local/lib/nemoclaw/hermes-runtime-config-guard.py
COPY agents/hermes/finalize-tirith-marker.py /usr/local/lib/nemoclaw/finalize-tirith-marker.py
COPY agents/hermes/build-mcp-digest.py /usr/local/lib/nemoclaw/build-hermes-mcp-digest.py
COPY agents/hermes/mcp-config-transaction.py /usr/local/lib/nemoclaw/hermes-mcp-config-transaction.py

COPY src/lib/actions/sandbox/openshell-child-visible-credentials.v0.0.85.json /usr/local/lib/nemoclaw/openshell-child-visible-credentials.v0.0.85.json

COPY scripts/state-dir-guard.py /usr/local/lib/nemoclaw/state-dir-guard.py
COPY nemoclaw-blueprint/scripts/*.js /usr/local/lib/nemoclaw/preloads/
COPY agents/hermes/hermes-wrapper.py /usr/local/lib/nemoclaw/hermes-wrapper.py

These paths appear to assume the repository root is the Docker build context, not agents/hermes/.

Docker resolves COPY sources relative to the build context, so these paths cannot exist when the build context is only agents/hermes/.

Verification

The directory does exist in the repository:

agents/hermes/plugin/

For example:

agents/hermes/plugin/
init.py
plugin.yaml
test_register_tools.py

The failure is specifically that Docker cannot find

agents/hermes/plugin/

inside the staged build context, because the build context itself is already agents/hermes/.

Additional observations

I also experimented with a minimal custom Dockerfile.

That Dockerfile built successfully with Docker itself and I was able to install additional Python packages such as:

firecrawl-py
tavily-python
duckduckgo-search

However, nemohermes onboard --from rejected the minimal Dockerfile because the onboard patcher expects the official Dockerfile contract (for example ARG NEMOCLAW_MESSAGING_PLAN_B64, ARG NEMOCLAW_TOOL_DISCLOSURE, etc.). This seems expected for custom Dockerfiles and is separate from the build-context issue.

Question

Is one of the following intended?

The build context should actually be the repository root instead of the Dockerfile's parent directory.
The official agents/hermes/Dockerfile should use paths relative to agents/hermes/.
--from is intended only for standalone Dockerfiles, and the repository Dockerfile is not expected to be used directly.

At the moment, the documented --from agents/hermes/Dockerfile workflow appears to fail because the staged build context and the Dockerfile's COPY paths do not match.

Description

nemohermes onboard --from agents/hermes/Dockerfile fails because the staged Docker build context doesn't match the Dockerfile

Reproduction Steps

Added

Environment

Added

Debug Output

Added

Logs

Added

Checklist

• I confirmed this bug is reproducible
• I searched existing issues and this is not a duplicate

[nvshaxie]

Thanks for the thorough investigation — your analysis is exactly right. To answer the question directly: the managed agents/hermes/Dockerfile is built internally with the repository root as the build context (see createAgentSandbox in src/lib/agent/base-image.ts), while --from documents and stages the Dockerfile's parent directory. Those two contracts can never meet for the managed Dockerfile, so the documented customize-by-editing-the-stock-Dockerfile workflow was broken.

Fix in #7208: when --from resolves to the selected agent's own managed Dockerfile, onboard now stages the repository root (identical to the managed build, including the ARG BASE_IMAGE pin), so nemohermes onboard --from agents/hermes/Dockerfile — including an edited-in-place copy with extra pip packages — builds correctly. Standalone custom Dockerfiles keep the parent-directory contract you observed.