Description
When onboarding builds the sandbox image from a local NemoClaw checkout, the staging step copies the whole nemoclaw-blueprint tree into the Docker build context (cp -r in bin/lib/onboard.js). If a developer (or any local workflow) has created a .venv directory under nemoclaw-blueprint—for example after running Python tooling, pytest, nv run, nv sync—that path is copied along with the rest of the blueprint and ends up in the image via COPY nemoclaw-blueprint/ in the Dockerfile.
That is problematic for two reasons:
Build failures — packaging can choke on or mishandle .venv in ways that don’t affect users who only use the released installer without a local .env.
Security — .venv often holds secrets; it must not be baked into image layers.
End users who never have a local .env under nemoclaw-blueprint may never see this, but the build path should be hygienic regardless.
Reproduction Steps
Repro (typical dev):
- Clone NemoClaw and work under nemoclaw-blueprint with Python (e.g. uv sync that create nemoclaw-blueprint/.venv).
Run onboarding so it builds the sandbox image from the local repo (e.g. nemoclaw onboard after curl … | bash or equivalent using this tree).
Observe build/packaging errors involving .venv, or inspect image/context and see .env included.
Expected: Local-only artifacts (at minimum .env, and ideally .venv / pycache / .pytest_cache) are excluded from the Docker build context when staging nemoclaw-blueprint.
Environment
openClaw: 2026.3.11 (29dc654)
OpenShell: 0.0.14
macOS 26.1 (Apple M4, arm64)
Policy presets applied: pypi, npm
Inference: NVIDIA Cloud API (nvidia/nemotron-3-super-120b-a12b)
Debug Output
Logs
Checklist
Description
When onboarding builds the sandbox image from a local NemoClaw checkout, the staging step copies the whole nemoclaw-blueprint tree into the Docker build context (cp -r in bin/lib/onboard.js). If a developer (or any local workflow) has created a .venv directory under nemoclaw-blueprint—for example after running Python tooling, pytest, nv run, nv sync—that path is copied along with the rest of the blueprint and ends up in the image via COPY nemoclaw-blueprint/ in the Dockerfile.
That is problematic for two reasons:
Build failures — packaging can choke on or mishandle .venv in ways that don’t affect users who only use the released installer without a local .env.
Security — .venv often holds secrets; it must not be baked into image layers.
End users who never have a local .env under nemoclaw-blueprint may never see this, but the build path should be hygienic regardless.
Reproduction Steps
Repro (typical dev):
Run onboarding so it builds the sandbox image from the local repo (e.g. nemoclaw onboard after curl … | bash or equivalent using this tree).
Observe build/packaging errors involving .venv, or inspect image/context and see .env included.
Expected: Local-only artifacts (at minimum .env, and ideally .venv / pycache / .pytest_cache) are excluded from the Docker build context when staging nemoclaw-blueprint.
Environment
openClaw: 2026.3.11 (29dc654)
OpenShell: 0.0.14
macOS 26.1 (Apple M4, arm64)
Policy presets applied: pypi, npm
Inference: NVIDIA Cloud API (nvidia/nemotron-3-super-120b-a12b)
Debug Output
Logs
Checklist