NanoClaw accepts Node 26 before its native database can build

nanocoai/nanoclaw issue #3359 is the inspected primary source: “setup: Node 26 passes check_node but better-sqlite3 11.10.0 cannot build against it.” The related records below were inspected as supporting context rather than independent confirmation.

The facts

- nanocoai/nanoclaw issue #3359 was created 2026-08-19T17:55:02Z and was open at inspection; its title is “setup: Node 26 passes check_node but better-sqlite3 11.10.0 cannot build against it.” - nanocoai/nanoclaw PR #3360 was created 2026-08-19T20:25:51Z and was open at inspection; its title is “fix: support current Node runtimes.” - nanocoai/nanoclaw issue #3354 was created 2026-08-19T14:52:21Z and was open at inspection; its title is “Setup leaves 0-byte channel files on a failed git-show copy, and an onecli check runs before its own PATH fix (non-login/headless install).” - The repository reported 30561 stars, 906 open issues, default branch main, and last push 2026-08-19T21:16:42Z. - The latest tagged-release baseline checked was v2.2.0 published 2026-08-13T20:43:27Z.

What changed

nanocoai/nanoclaw issue #3359 reports: What happens** On a fresh macOS arm64 machine with Homebrew's current Node (26.7.0), bash nanoclaw.sh passes the Node check and then aborts at bootstrap with deps_failed. better-sqlite3 fails to compile. Why it happens** check_node in setup.sh only has a lower bound ([ "$major" -ge 20 ]), and package.json says "node": ">=20" with no cap. Verified at 882305eb. better-sqlite3 is pinned at 11.10.0. That release has no prebuilt binary for Node 26: so the install falls back to node-gyp, and the 11.x sources use V8 APIs that Node 26 removed: The break is exactly at Node 26. I built better-sqlite3 11.10.0 from source on this machine to bracket it: it compiles and loads on Node 24.14.1 and 25.9.0, and fails on 26.7.0. How to see it** macOS arm64, brew install node (installs 26.7.0 today), then bash nanoclaw.sh. Bootstrap fails during pnpm install --frozen-lockfile. The same checkout installs cleanly with Node 22.23.2 first in PATH (DEPS_OK: true, NATIVE_OK: true). Suggested fix** Two parts, they are independent: 1. Bump better-sqlite3 to the 12.x line. I checked 12.11.1: its engines field is 20.x || 22.x || 23.x || 24.x || 25.x || 26.x, and it installs and loads fine on Node 26.7.0 (prebuilt binary, no compile step). 13.x also works on Node 26 but needs Node 22 or higher, so it would drop Node

nanocoai/nanoclaw PR #3360 reports: Summary Upgrade better-sqlite3 from 11.10.0 to 13.0.3 for current Node runtime support. Raise the host minimum from Node.js 20 to Node.js 22 across package metadata, setup, CI, documentation, and the changelog. Make the uvx nodeenv fallback replace an existing ~/node installation when upgrading. Test the host on both Node.js 22 and Node.js 24 in CI. Root cause better-sqlite3 11.10.0 is incompatible with Node.js 24. The setup fallback also failed to upgrade older local Node installations when ~/node already existed because nodeenv refuses to reuse that directory without --force. Impact Node.js 20 users must upgrade to Node.js 22 or newer. The setup script now performs that upgrade correctly, and the breaking changelog entry includes the migration command. Validation pnpm install --frozen-lockfile pnpm run build pnpm test on Node.js 22.22.2 — 147 files, 1,862 tests passed pnpm test on Node.js 24.19.0 — 147 files, 1,862 tests passed bash -n setup.sh bash -n setup/install-node.sh git diff --check

nanocoai/nanoclaw issue #3354 reports: Two setup-time bugs surface when NanoClaw is installed over a non-login ssh session (no interactive shell, ~/.local/bin not yet on PATH). Both were hit on a clean box. They are unrelated in mechanism but share a cause: setup assumes an interactive/login shell. Bug 1: git show: > truncates the destination before git runs Three setup paths copy a file out of a git ref with a shell redirect: scripts/skill-apply.ts:653 - git show ${remote}/${b}:${srcOf(l)} > ${destOf(l)} setup/channels/slack-auto.ts:146 - git show ${remote}/${CHANNELS_BRANCH}:${PROVISIONING_MODULE} > ${PROVISIONING_MODULE} setup/install-github.sh:32 - git show origin/channels:src/channels/github.ts > src/channels/github.ts skill-apply.ts:653 and install-github.sh:32 can truncate a file that already exists; slack-auto.ts:146 only runs when the file is absent, so there it writes a 0-byte stub of a missing file rather than truncating existing content. Either way the destination is opened and emptied by > before git show runs. If git show then fails (ref missing, path not in the ref, network), the destination is left as a 0-byte stub. The git error itself is still reported (it goes to stderr, which the redirect does not touch); the silent part is the stub, which a retry then reads as if it were the real file. Seen on a clean install: git show failed with path 'src/channels/dial.ts' exists on disk, but not in 'upstream/channels' (a merge-order condition, expected), but the copy step

Why it matters

Installers must reject unsupported combinations before mutating a workspace. Passing the first check and failing after partial writes leaves operators with an ambiguous, harder-to-repair state. 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-20. 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/3359. Supporting records are https://github.com/nanocoai/nanoclaw/pull/3360 and https://github.com/nanocoai/nanoclaw/issues/3354. 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

Test the exact Node and native-module matrix up front, stage generated channel files atomically, and verify PATH fixes before invoking dependent tools. 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.