NanoClaw

NanoClaw confronts old Node installs and AVX2-only images

NanoClaw users report a setup branch that detects an old Node version but cannot replace it, plus a prebuilt Bun image that can crash with SIGILL on CPUs without AVX2. A proposed setup fix handles the stale runtime path.

← Back to homeOriginal source ↗

nanocoai/nanoclaw issue #3248 is the inspected primary source: “setup.sh's "Node missing or too old" branch cannot handle too old, because install-node.sh short-circuits on any node.” The related records below were inspected as supporting context rather than independent confirmation.

The facts

- nanocoai/nanoclaw issue #3248 was created 2026-08-14T21:30:23Z and was open at inspection; its title is “setup.sh's "Node missing or too old" branch cannot handle too old, because install-node.sh short-circuits on any node.” - nanocoai/nanoclaw PR #3249 was created 2026-08-14T22:17:18Z and was open at inspection; its title is “fix(setup): handle an existing Node that is too old.” - nanocoai/nanoclaw issue #3245 was created 2026-08-14T13:38:41Z and was open at inspection; its title is “Prebuilt agent image: Bun binary requires AVX2 — SIGILL on CPUs without it.” - The repository reported 30510 stars, 882 open issues, default branch main, and last push 2026-08-14T08:54:26Z. - The latest tagged-release baseline checked was v2.2.0 published 2026-08-13T20:43:27Z.

What changed

nanocoai/nanoclaw issue #3248 reports: setup.sh version-checks Node (check_node, setup.sh#L51-L68: major >= 20 sets NODE_OK) and routes both failure modes into the helper: the branch at setup.sh#L186-L195 logs "Node missing or too old — running setup/install-node.sh". That routing is intentional: fd2e404b says "Node check now triggers setup/install-node.sh when missing/too old". But setup/install-node.sh#L13-L18 exits 0 with STATUS: already-installed the moment any node is on the PATH, with no version check, so its install branches are unreachable in the too-old case. The helper no-ops successfully, check_node re-runs, NODE_OK stays false, and the run ends STATUS=node_missing with exit 2 (setup.sh#L201-L202, setup.sh#L242-L244). Nothing downstream rescues it: install_deps returns before any pnpm call when NODE_OK is false (setup.sh#L76-L79), so the package.json engines requirement is never even evaluated, and nanoclaw.sh has no Node gate of its own. On a machine with Node 18 the failure dump shows "Node not found — installing via setup/install-node.sh", a success-looking helper block, then node_missing, even though node exists. No message names the required version or says the fix is upgrading the existing Node. I think I hit exactly this during a live demo on a webinar: setup said it was installing Node, then failed with node_missing on a machine that already had an older Node. Cheap fix: make the helper detect the too-old case and

nanocoai/nanoclaw PR #3249 reports: Type of Change [ ] **Feature skill** - adds a channel or integration (source code changes + SKILL.md) [ ] **Utility skill** - adds a standalone tool (code files in.claude/skills/ /, no source changes) [ ] **Operational/container skill** - adds a workflow or agent skill (SKILL.md only, no source changes) [x] **Fix** - bug fix or security fix to source code [ ] **Simplification** - reduces or simplifies source code [ ] **Documentation** - docs, README, or CONTRIBUTING changes only Description Closes #3248. setup.sh routes "Node missing or too old" into setup/install-node.sh, but the helper short-circuits on any node on the PATH with no version check. With an old Node, setup says it is installing Node, the helper no-ops as already-installed, and the run dies STATUS=node_missing. Now: Interactive runs with an old Node get a consent prompt (same shape as the Homebrew one). Accept: the helper installs a new Node, with nodeenv next to the existing one when uvx is available, the platform installer otherwise. Decline: setup exits with the manual fix. Headless runs fail clearly instead: STATUS=node_too_old with the required version named. Exit code stays 2. The helper's final check is version-aware, so an old Node still shadowing the new one fails loudly. brew's node@22 is keg-only, so

nanocoai/nanoclaw issue #3245 reports: Summary The prebuilt agent image pulled by default during setup (NANOCLAW_HARDENED_IMAGE=true, which is what the wizard recommend) contains a Bun binary built for the non-baseline x64 target (requires AVX2). On CPUs without AVX2 — e.g. Intel Tremont/Elkhart Lake Atoms (Celeron J6413/N5105/N6005 family), common on homelab/NAS/mini-PC hardware — every Bun invocation dies with SIGILL, so every spawned agent container dies before the agent-runner even starts. The failure is completely silent: no error reaches the user or logs/nanoclaw.error.log, just an endless retry loop. Environment CPU: Intel Celeron J6413 (Tremont, no AVX/AVX2) OS: Debian 13 (trixie) Docker Engine: 29.7.2 Image: pulled via official setup's hardened-image default, pin from versions.json: 797273591697.dkr.ecr.us-east-1.amazonaws.com/nanoclaw/agent@sha256:ccde3d9c86fb655be66c93e07bc38a62faab2d951651a1fba345a7a47defeb85 Repro (No stdout/stderr — the process is killed silently by SIGILL. The image's ENTRYPOINT is tini -- /app/entrypoint.sh, so a bare docker run --rm bun --version will not reproduce this directly; --entrypoint bash -c "bun --version" is needed to invoke bun by itself.) Impact / why this is hard to diagnose From the host's perspective, everything looks normal right up to the crash: \\\ INFO Message routed... wake=true INFO Initialized group filesystem... INFO OneCLI gateway applied containerName=... INFO Spawning container... INFO Container exited... code=132 \\\ This repeats every ~60s (host-sweep retry) forever. code=132 is never surfaced as an error,

Why it matters

“Installed” is not the same as compatible. Bootstrap logic and prebuilt images must test minimum runtime and CPU capabilities before starting a container that cannot execute. The operator test is whether the system remains bounded and its receipts still describe the action after failure, retry or restart.

Current

The primary record was open when captured on 2026-08-15. The tagged-release baseline was v2.2.0 published 2026-08-13T20:43:27Z. Repository metadata, full source bodies, current pull requests and issues, releases, Google News, Hacker News, Lobsters, Metamesh and the rendered ClawCharts row were inspected. ClawCharts selected the subject; it did not prove the claim.

Evidence

The primary URL is https://github.com/nanocoai/nanoclaw/issues/3248. Supporting records are https://github.com/nanocoai/nanoclaw/pull/3249 and https://github.com/nanocoai/nanoclaw/issues/3245. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts and reproductions remain attributed to their authors unless identified as independently rerun.

Source boundary

Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.

Operator take

Add preflight checks for Node version and CPU flags, publish image compatibility metadata, and keep a tested source-build or alternate-image path for older hosts. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently.

Caveat

Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.

Source inspected; source state, environment and release boundary remain explicit.