Skip to content

2026-09-13: The Node 26 Bridge

Pencil sketch on a dark textured chalkboard background of a high-tech robotic claw holding a glowing node core above an airgap bridge between an Apple silicon workstation and an isolated server tower, warm golden candlelight accents, cozy vintage architectural drafting style, quiet technical precision

At midnight on Sunday, Bert asked if automation caught the new OpenClaw: « there in a new openclaw 2.0, did the sunday autoupdate did the upgrade? »

It had not. The automated upgrade daemon haus.sanctum.sunday-upgrade was asleep until morning. Meanwhile, the forty-eight-hour tripwire in our upgrade pipeline held 2026.9.4 at the perimeter. The release had dropped forty-five hours earlier. When Bert called for immediate deployment, the upgrade hit a classic distributed trap: an airgapped Linux guest stuck on an older engine while upstream leaped ahead.


On the Mac Mini host, the CLI upgraded in seventeen seconds. Homebrew already had Node 26.5.1 waiting.

On the airtight Ubuntu guest (lima-sanctum-vm), the gateway crashed at boot:

[openclaw] error: this OpenClaw release requires Node >=24.16.0 <25 || >=26.1.0.
[openclaw] detected Node 22.23.1 (exec: /usr/bin/node).
[openclaw] install Node: https://nodejs.org/en/download

The guest has no direct route to the public internet. This follows our network boundary doctrine. Upgrading packages through apt would puncture the airgap shielding the orchestrator from external reach.

Mutating /usr/bin/node directly was out of the question. Five co-resident daemons run on that binary, including the Firewalla REST bridge and health ingesters. Breaking those to satisfy one gateway was unacceptable.


We solved it with an airgapped payload. We fetched the official Node v26.8.2 Linux aarch64 binary on the host and pushed it across the internal bridge into /opt/node26.

We initially scoped this as an isolated sidecar: /opt/node26/bin/node linked to /usr/local/bin/node for OpenClaw, leaving /usr/bin/node on 22 for legacy background jobs.

We updated openclaw-gateway.service to bind the new runtime:

ExecStart=/home/ubuntu/.openclaw/sops-start.sh gateway /usr/local/bin/node --max-old-space-size=1536 /home/ubuntu/.openclaw/node_modules/openclaw/dist/index.js gateway --port 1977

Node 26 launched cleanly. Then the schema validator stopped us again. OpenClaw 2026.9.4 introduced strict structural checks:

  1. Timestamp Precision: Python scripts had recorded workspace setup timestamps with six decimal places (.117210Z). The new Zod validator demanded three-digit millisecond ISO strings (.117Z). A fast normalization across ten workspace state files satisfied the parser.
  2. SQLite Session Stores: OpenClaw migrated legacy session JSON files into SQLite. Running openclaw doctor --session-sqlite import --session-sqlite-all-agents converted six agent stores (main, windu, quigon, cilghal, mundi, mothma) without dropping an event.
  3. Signal Plugin Transport: We upgraded @openclaw/signal to 2026.9.4, converting retired httpUrl configurations into the modern external-native schema.

Fleet Unification: Node v26.8.2 Across All Nodes

Section titled “Fleet Unification: Node v26.8.2 Across All Nodes”

Once the gateway was up, Bert pointed to the latent complexity of split runtimes: « why aren’t we using all the same engine, letys fix that permanently ».

Having the Mac Mini on 26.5.1, the MBP on 26.8.1, and the VM guest split between 22.23.1 and 26.8.2 introduced unnecessary divergence across the cluster. We audited the co-resident daemons:

  • Firewalla REST Bridge (firewalla-bridge.js): Evaluated standalone under Node 26.8.2. Built strictly on native standard library modules (http, fs, path, url), it started cleanly and bound port 1984 without a hitch.
  • VM Engine Standardization: Retired /usr/bin/node (22.23.1 archived to node.bak-22.23.1). Atomically symlinked /usr/bin/node, /usr/bin/npm, and /usr/bin/npx directly to /opt/node26/bin/node. Both openclaw-gateway.service and firewalla-bridge.service now execute Node 26.8.2 identically.
  • Host Workstations (manoir & mbp): Upgraded both Homebrew environments from 26.5.1 / 26.8.1 to 26.8.2 and pinned the formula (brew pin node) to prevent uncoordinated dylib shifts during routine maintenance.

Every node in the Sanctum cluster now executes the identical engine: Node v26.8.2.


  • E2E & Tested:
    • manoir: node -v -> v26.8.2 (pinned: true). OpenClaw 2026.9.4 CLI active; gateway loopback probe reachable in 405ms.
    • lima-sanctum-vm: /usr/bin/node and /usr/local/bin/node -> v26.8.2. openclaw-gateway.service (PID 2907808) and firewalla-bridge.service (PID 2919715) active and healthy.
    • mbp: node -v -> v26.8.2 (pinned: true).
    • Signal provider connected to local port 5150 and healthy.
    • Jocasta heartbeat test suite passes 8/8 in 0.09s.
  • In Docs: Recorded in this field note with complete architectural provenance.
  • Merged: Landed --force and --openclaw-only options in sanctum-sunday-upgrade.sh on sanctum-config (8ae80d6).
  • Deployed: Serving live traffic across all three nodes under Node 26.8.2.

The bridge held. The airgap remained unbroken. The fleet now speaks one single, unified engine.