Description
Description
After running `npm install` from a fresh git clone of NemoClaw on a Linux host without sudo or a user-writable global npm prefix configured, npm install reports "success" but the `nemoclaw` command is not actually available on PATH. Root cause: the `prepare` script in package.json calls `npm link` with both stderr and exit code suppressed (`2>/dev/null || true`), so any link failure is hidden from the user. The user only discovers it when they run `nemoclaw onboard` and get "No such file or directory".
The curl|bash installer handles this case gracefully by falling back to a user-local shim at `~/.local/bin/nemoclaw`. The dev install path should match that behavior, or at minimum surface the link failure clearly.
Environment
Device: Ubuntu host (2u1g-b650-0082)
OS: Ubuntu (version not captured)
Architecture: x86_64
Node.js: v22.22.2
npm: 10.9.7
Docker: not captured
OpenShell CLI: 0.0.36
NemoClaw: v0.0.26 (git tag, commit 5653d33a)
OpenClaw: N/A (onboard not reached due to missing CLI)
Steps to Reproduce
1. On a fresh Linux host without a writable global npm prefix and without sudo configured for npm:
git clone https://github.com/NVIDIA/NemoClaw.git
2. cd NemoClaw && git checkout v0.0.26
3. npm install
(npm reports success, all packages installed, no errors visible)
4. cd nemoclaw && npm install && npm run build && cd ..
(also reports success)
5. nemoclaw onboard
Expected Result
Either:
(a) `npm install` fails clearly with a permission error stating `npm link` could not write to the global prefix, with a hint about fixing it (use sudo, or set `npm config set prefix ~/.npm-global`); OR
(b) `npm install` succeeds and `nemoclaw` is a working command — e.g. via fallback to user-local shim like `~/.local/bin/nemoclaw`, matching the behavior of the curl|bash installer ("Created user-local shim at /home/.../.local/bin/nemoclaw").
Actual Result
Steps 3 and 4 both report success with no warnings. Step 5 fails:
$ nemoclaw onboard
bash: /localhome/local-glennz/.local/bin/nemoclaw: No such file or directory
After clearing bash's hash cache (`hash -r`), `which nemoclaw` returns nothing — the dev install never actually created any `nemoclaw` command, despite npm install reporting success.
Workaround: manually run `npm link` (with sudo if a writable prefix isn't configured) inside the NemoClaw repo after `npm install`.
Logs
$ npm install
> nemoclaw@0.1.0 prepare
> if command -v tsc >/dev/null 2>&1 || [ -x node_modules/.bin/tsc ]; then npm run build:cli; fi && (npm install --omit=dev --ignore-scripts 2>/dev/null || true) && if [ -d .git ]; then if [ -z "${NEMOCLAW_INSTALLING:-}" ]; then NEMOCLAW_INSTALLING=1 npm link 2>/dev/null || true; fi; ... fi
> nemoclaw@0.1.0 build:cli
> tsc -p tsconfig.src.json && tsc -p nemoclaw-blueprint/tsconfig.json
up to date, audited 7 packages in 267ms
...
added 294 packages, and audited 295 packages in 4s
(no errors; npm install reports success)
$ nemoclaw onboard
bash: /localhome/local-glennz/.local/bin/nemoclaw: No such file or directory
Offending pattern in the prepare script:
NEMOCLAW_INSTALLING=1 npm link 2>/dev/null || true
Both stderr (`2>/dev/null`) and exit code (`|| true`) are suppressed, hiding any link failure from the user.
Suggested Fix
Pick one of:
(a) Remove `2>/dev/null` and `|| true` from the prepare script's `npm link` call so errors propagate to the user. Add a clear hint about common fixes (sudo, npm prefix).
(b) Match the curl|bash installer behavior — when `npm link` fails, fall back to a user-local shim:
NEMOCLAW_INSTALLING=1 npm link 2>/tmp/nemoclaw-link.log
if [ $? -ne 0 ]; then
mkdir -p "$HOME/.local/bin"
ln -sf "$PWD/bin/nemoclaw" "$HOME/.local/bin/nemoclaw"
echo "[INFO] Created user-local shim at $HOME/.local/bin/nemoclaw"
fi
(c) At minimum, after `npm install` completes, print a verification line:
"Verified: nemoclaw is available at
Bug Details
| Field |
Value |
| Priority |
Unprioritized |
| Action |
Dev - Open - To fix |
| Disposition |
Open issue |
| Module |
Machine Learning - NemoClaw |
| Keyword |
NemoClaw, NEMOCLAW_GH_SYNC_APPROVAL, NemoClaw_Install |
[NVB#6116097]
Description
Description
Environment Steps to Reproduce Expected ResultEither: (a) `npm install` fails clearly with a permission error stating `npm link` could not write to the global prefix, with a hint about fixing it (use sudo, or set `npm config set prefix ~/.npm-global`); OR (b) `npm install` succeeds and `nemoclaw` is a working command — e.g. via fallback to user-local shim like `~/.local/bin/nemoclaw`, matching the behavior of the curl|bash installer ("Created user-local shim at /home/.../.local/bin/nemoclaw").Actual Result Logs$ npm install > nemoclaw@0.1.0 prepare > if command -v tsc >/dev/null 2>&1 || [ -x node_modules/.bin/tsc ]; then npm run build:cli; fi && (npm install --omit=dev --ignore-scripts 2>/dev/null || true) && if [ -d .git ]; then if [ -z "${NEMOCLAW_INSTALLING:-}" ]; then NEMOCLAW_INSTALLING=1 npm link 2>/dev/null || true; fi; ... fi > nemoclaw@0.1.0 build:cli > tsc -p tsconfig.src.json && tsc -p nemoclaw-blueprint/tsconfig.json up to date, audited 7 packages in 267ms ... added 294 packages, and audited 295 packages in 4s (no errors; npm install reports success) $ nemoclaw onboard bash: /localhome/local-glennz/.local/bin/nemoclaw: No such file or directory Offending pattern in the prepare script: NEMOCLAW_INSTALLING=1 npm link 2>/dev/null || true Both stderr (`2>/dev/null`) and exit code (`|| true`) are suppressed, hiding any link failure from the user.Suggested FixPick one of: (a) Remove `2>/dev/null` and `|| true` from the prepare script's `npm link` call so errors propagate to the user. Add a clear hint about common fixes (sudo, npm prefix). (b) Match the curl|bash installer behavior — when `npm link` fails, fall back to a user-local shim: NEMOCLAW_INSTALLING=1 npm link 2>/tmp/nemoclaw-link.log if [ $? -ne 0 ]; then mkdir -p "$HOME/.local/bin" ln -sf "$PWD/bin/nemoclaw" "$HOME/.local/bin/nemoclaw" echo "[INFO] Created user-local shim at $HOME/.local/bin/nemoclaw" fi (c) At minimum, after `npm install` completes, print a verification line: "Verified: nemoclaw is available atBug Details
[NVB#6116097]