Skip to content

[macOS][Onboard] v0.0.45 sandbox build fails on RUN npm ci: nemoclaw/package-lock.json out of sync (regression of #2760) #3798

@bitnahian

Description

@bitnahian

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):

  1. curl -fsSL https://www.nvidia.com/nemoclaw.sh | NEMOCLAW_ACCEPT_THIRD_PARTY_SOFTWARE=1 NEMOCLAW_INSTALL_TAG=v0.0.45 bash
  2. 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:

  1. 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.

  2. 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

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

Metadata

Metadata

Assignees

Labels

area: installInstall, setup, prerequisites, or uninstall flowarea: onboardingOnboarding FSM, provider setup, sandbox launch, or first-run flowplatform: macosAffects macOS, including Apple Silicon

Type

No fields configured for Bug.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions