Description
Fresh install of NemoClaw v0.0.45 fails during onboarding when the sandbox image builds. Step 7/70 of the Dockerfile (RUN npm ci && npm run build) crashes with:
npm error Missing: @emnapi/core@1.10.0 from lock file
npm error Missing: @emnapi/runtime@1.10.0 from lock file
npm error Missing: @emnapi/core@1.9.2 from lock file
npm error Missing: @emnapi/runtime@1.9.2 from lock file
This is the same symptom as #2760 (closed as "fixed on main"), but the fix referenced in that issue's closing comment only addressed the root package-lock.json. The sandbox image is built from the nemoclaw/ subdirectory's package-lock.json (Dockerfile step 4/70: COPY nemoclaw/package.json nemoclaw/package-lock.json …), and that lockfile has drifted again in v0.0.45.
There are two distinct lockfiles in the repo, both for packages literally named "nemoclaw":
- root
package.json / package-lock.json — host CLI build (validated, in sync)
nemoclaw/package.json / nemoclaw/package-lock.json — payload baked into the sandbox image at build time (not in sync)
CI presumably only runs npm ci against the root, which is why the regression slipped past the v0.0.45 release.
Why the obvious workaround doesn't work
It is tempting to tell users to just run cd ~/.nemoclaw/source/nemoclaw && npm install --package-lock-only and move on. This does not fix the build, and the failure mode is subtle:
@napi-rs/wasm-runtime@1.1.4 (the package whose deps are missing) declares @emnapi/core and @emnapi/runtime as optional, platform-conditional transitive deps — they are a WASI fallback that npm's resolver only includes on Linux. As a result:
Where you run npm install --package-lock-only |
Resulting nemoclaw/package-lock.json |
npm ci --dry-run on macOS |
npm ci inside node:22-trixie-slim (the build container) |
| macOS host (default for most users) |
node_modules/@emnapi/{core,runtime} entries pruned |
✅ passes |
❌ same Missing: @emnapi/... error |
| Linux container with the same node image |
node_modules/@emnapi/{core,runtime} entries present |
✅ passes |
✅ passes |
Concretely, on macOS a freshly regenerated nemoclaw/package-lock.json only contains:
$ grep -E '"node_modules/@emnapi' nemoclaw/package-lock.json
"node_modules/@emnapi/wasi-threads": {
After regenerating inside the Linux build image:
$ grep -E '"node_modules/@emnapi' nemoclaw/package-lock.json
"node_modules/@emnapi/core": {
"node_modules/@emnapi/runtime": {
"node_modules/@emnapi/wasi-threads": {
The two Missing: @emnapi/core@1.10.0 / 1.9.2 lines in the build error output above come from these two regenerate paths — they're the same drift, just resolved by different npms.
Diagnostic
In a v0.0.45 source clone (~/.nemoclaw/source):
| Lockfile |
Path |
npm ci --dry-run result |
| Root |
package-lock.json |
✅ in sync |
| Subdir (as shipped) |
nemoclaw/package-lock.json |
❌ Missing @emnapi/core@1.9.2, @emnapi/runtime@1.9.2 (macOS) / @1.10.0 (Linux) |
$ cd ~/.nemoclaw/source/nemoclaw && npm ci --ignore-scripts --dry-run
npm error code EUSAGE
npm error `npm ci` can only install packages when your package.json and
package-lock.json or npm-shrinkwrap.json are in sync.
npm error Missing: @emnapi/core@1.9.2 from lock file
npm error Missing: @emnapi/runtime@1.9.2 from lock file
Reproduction Steps
Reproduces on a fully clean machine (no prior NemoClaw state, no leftover sandbox containers):
curl -fsSL https://www.nvidia.com/nemoclaw.sh | NEMOCLAW_ACCEPT_THIRD_PARTY_SOFTWARE=1 NEMOCLAW_INSTALL_TAG=v0.0.45 bash
- The installer's auto-onboard at step [3/8] reaches the sandbox-build step and fails at Dockerfile Step 7/70 (
RUN npm ci && npm run build).
Standalone reproduction without onboarding the agent:
cd ~/.nemoclaw/source/nemoclaw && npm ci --ignore-scripts --dry-run
Working workaround
Regenerate the lockfile inside the same Linux image used by the sandbox build, not on the host:
cd ~/.nemoclaw/source/nemoclaw
docker run --rm -v "$PWD":/work -w /work node:22-trixie-slim \
sh -c 'npm install --package-lock-only --ignore-scripts'
After this, npm ci --dry-run passes both on the macOS host and inside the build container, and nemoclaw onboard --resume proceeds past Step 7/70.
Environment
- OS: macOS 26.4.1 (Apple Silicon, M4 Pro)
- Docker: Docker Desktop 29.4.3
- Node.js (host): v25.1.0
- npm (host): 11.6.2
- Node.js (build container,
node:22-trixie-slim@sha256:2d9f5c76…): v22.22.2
- npm (build container): 10.9.7
- NemoClaw: v0.0.45
- OpenShell CLI: 0.0.39
- OpenClaw payload pinned by
Dockerfile.base: OPENCLAW_VERSION=2026.4.24
Logs
Step 7/70 : RUN npm ci && npm run build
---> Running in fae9aa9c7d76
npm error code EUSAGE
npm error `npm ci` can only install packages when your package.json and package-lock.json or npm-shrinkwrap.json are in sync. Please update your lock file with `npm install` before continuing.
npm error Missing: @emnapi/core@1.10.0 from lock file
npm error Missing: @emnapi/runtime@1.10.0 from lock file
npm error Missing: @emnapi/core@1.9.2 from lock file
npm error Missing: @emnapi/runtime@1.9.2 from lock file
Error: × Docker build stream error
╰─▶ Docker stream error: The command '/bin/sh -c npm ci && npm run build'
returned a non-zero code: 1
Suggested fix
Two parts, both needed:
-
Re-sync nemoclaw/package-lock.json against nemoclaw/package.json by regenerating it inside the same Linux image the sandbox Dockerfile uses (node:22-trixie-slim pinned by SHA in Dockerfile). Regenerating on a maintainer's macOS dev machine will reintroduce this same bug, just with platform-specific optional deps stripped from the lockfile rather than missing.
-
Add a CI guard that runs npm ci --ignore-scripts --dry-run against nemoclaw/package-lock.json on Linux, in addition to the existing root-level check. A guard that only runs on the maintainer's local platform won't catch this — the problem is precisely the macOS↔Linux divergence in optional-dep resolution.
Checklist
Description
Fresh install of NemoClaw v0.0.45 fails during onboarding when the sandbox image builds. Step 7/70 of the Dockerfile (
RUN npm ci && npm run build) crashes with:This is the same symptom as #2760 (closed as "fixed on
main"), but the fix referenced in that issue's closing comment only addressed the rootpackage-lock.json. The sandbox image is built from thenemoclaw/subdirectory'spackage-lock.json(Dockerfile step 4/70:COPY nemoclaw/package.json nemoclaw/package-lock.json …), and that lockfile has drifted again in v0.0.45.There are two distinct lockfiles in the repo, both for packages literally named
"nemoclaw":package.json/package-lock.json— host CLI build (validated, in sync)nemoclaw/package.json/nemoclaw/package-lock.json— payload baked into the sandbox image at build time (not in sync)CI presumably only runs
npm ciagainst the root, which is why the regression slipped past the v0.0.45 release.Why the obvious workaround doesn't work
It is tempting to tell users to just run
cd ~/.nemoclaw/source/nemoclaw && npm install --package-lock-onlyand move on. This does not fix the build, and the failure mode is subtle:@napi-rs/wasm-runtime@1.1.4(the package whose deps are missing) declares@emnapi/coreand@emnapi/runtimeas optional, platform-conditional transitive deps — they are a WASI fallback that npm's resolver only includes on Linux. As a result:npm install --package-lock-onlynemoclaw/package-lock.jsonnpm ci --dry-runon macOSnpm ciinsidenode:22-trixie-slim(the build container)node_modules/@emnapi/{core,runtime}entries prunedMissing: @emnapi/...errornode_modules/@emnapi/{core,runtime}entries presentConcretely, on macOS a freshly regenerated
nemoclaw/package-lock.jsononly contains:After regenerating inside the Linux build image:
The two
Missing: @emnapi/core@1.10.0/1.9.2lines in the build error output above come from these two regenerate paths — they're the same drift, just resolved by different npms.Diagnostic
In a v0.0.45 source clone (
~/.nemoclaw/source):npm ci --dry-runresultpackage-lock.jsonnemoclaw/package-lock.json@emnapi/core@1.9.2,@emnapi/runtime@1.9.2(macOS) /@1.10.0(Linux)Reproduction Steps
Reproduces on a fully clean machine (no prior NemoClaw state, no leftover sandbox containers):
curl -fsSL https://www.nvidia.com/nemoclaw.sh | NEMOCLAW_ACCEPT_THIRD_PARTY_SOFTWARE=1 NEMOCLAW_INSTALL_TAG=v0.0.45 bashRUN npm ci && npm run build).Standalone reproduction without onboarding the agent:
Working workaround
Regenerate the lockfile inside the same Linux image used by the sandbox build, not on the host:
After this,
npm ci --dry-runpasses both on the macOS host and inside the build container, andnemoclaw onboard --resumeproceeds past Step 7/70.Environment
node:22-trixie-slim@sha256:2d9f5c76…): v22.22.2Dockerfile.base:OPENCLAW_VERSION=2026.4.24Logs
Suggested fix
Two parts, both needed:
Re-sync
nemoclaw/package-lock.jsonagainstnemoclaw/package.jsonby regenerating it inside the same Linux image the sandbox Dockerfile uses (node:22-trixie-slimpinned by SHA inDockerfile). Regenerating on a maintainer's macOS dev machine will reintroduce this same bug, just with platform-specific optional deps stripped from the lockfile rather than missing.Add a CI guard that runs
npm ci --ignore-scripts --dry-runagainstnemoclaw/package-lock.jsonon Linux, in addition to the existing root-level check. A guard that only runs on the maintainer's local platform won't catch this — the problem is precisely the macOS↔Linux divergence in optional-dep resolution.Checklist