compat: BrowserPod 2.12.1 guest Node has no node:sqlite binding — blocks preflight independent of the Node-version gate

[yhay81]

Finding

Two local, owner-authorized capture attempts against the pinned openclaw@2026.5.7 target (engines >=22.14.0, satisfied by the guest's Node 22.15.0 — see #6) both failed at the same preflight_failed gate in browserpod-openclaw-probe.mjs:78. Temporary local debug logging of the preflight probe's own output (never committed) showed the actual guest evidence:

{"node":"22.15.0","platform":"linux","arch":"wasm32","cryptoVerify":true,"sqlite":false,"sqliteError":"No such binding: sqlite"}

cryptoVerify passes. node:sqlite fails to load entirely — this is not a version-range mismatch (the kind #6 documents), it is the guest's Node build lacking the node:sqlite binding at all. The preflight probe (browserpod-preflight.mjs) runs exactly:

const { DatabaseSync } = require("node:sqlite");
const db = new DatabaseSync(":memory:");
db.exec("select 1");
db.close();

which throws before ever touching OpenClaw.

Why this is a separate blocker from #6

#6 tracks the Node version gate (22.15.0 < the artifact's required >=22.x baseline) — a moving target that a vendor Node bump could close. This finding is orthogonal: the check requires preflight.checks.cryptoVerify && preflight.checks.sqlite (browserpod-openclaw-probe.mjs:77-78), and sqlite fails regardless of which OpenClaw/Node-baseline target is selected, because it is about whether the binding was compiled into BrowserPod's Wasm Node build, not which Node version string it reports. Even a future BrowserPod release that satisfies the 22.19+ (or the current stable's compound >=22.22.3 <23 || >=24.15.0 <25 || >=25.9.0) baseline would still fail here unless that release also adds node:sqlite.

Reproduction

Owner-authorized, local (not CI — see #6's separate datacenter-IP finding), targeting the pinned older-baseline report:

$env:BROWSERPOD_API_KEY = "<your key>"
$env:CLAWSEMBLY_EVIDENCE_REPORT = "apps/web/public/data/releases/openclaw-2026.5.7.json"
npm ci --prefix examples/browserpod-evidence-host --ignore-scripts
node examples/browserpod-evidence-host/capture.mjs

Fails with preflight_failed; test-results/browserpod-evidence/capture-status.json records errorCode: "preflight_failed", failedStage: "capture-run", phaseCounts.preflight: {chunks:1, bytes:152} (the redacted evidence path deliberately keeps the raw probe JSON out of committed output, per the project's evidence-safety design; the JSON above was captured only through temporary, non-committed local debug logging for this report).

Suggested next steps

• File this neutrally with Leaning Tech (same channel as the compat: capture owner-authorized BrowserPod 2.12.1 Gateway evidence #6 vendor report) alongside the existing Node-baseline finding, since a fix likely means compiling node:sqlite into the Wasm Node build, not just bumping the reported version.
• Until resolved, no further metered capture attempts against any tracked or pinned report are expected to get past preflight — worth noting in the owner runbook so future attempts aren't spent rediscovering this.
• Open question for maintainer judgment (not decided here): whether node:sqlite is a hard OpenClaw runtime requirement worth keeping as a preflight gate as-is, or whether it should be downgraded to a recorded capability limitation if OpenClaw's actual 2026.5.7-era usage of it turns out to be optional — out of scope for this issue to decide.

[yhay81]

Verification complete — confirmed on the latest vendor runtime, and no client-side fix exists

The finding is now verified at three independent levels, including one fresh empirical probe against the latest BrowserPod 2.14.0 runtime (one additional owner-authorized metered boot, minimal probe only — no OpenClaw install).

1. The guest really lacks the binding — including on 2.14.0

Direct probe result from the 2.14.0 runtime (https://rt.browserpod.io/2.14.0/browserpod.js, minimal boot + staged probe.cjs):

{
  "node": "22.15.0",
  "platform": "linux",
  "arch": "wasm32",
  "cryptoVerify": true,
  "sqlite": false,
  "sqliteError": "No such binding: sqlite"
}

Two details sharpen the diagnosis:

• process.versions still advertises "sqlite": "3.49.1" — the build metadata inherited from stock Node 22.15.0 claims SQLite is bundled — yet require("node:sqlite") throws No such binding: sqlite and the guest's require("node:module").builtinModules (65 entries) does not list sqlite (it does list crypto, fs, worker_threads, etc.). So the builtin registration/binding is excluded from the vendor's Node-on-Wasm build while the version table says otherwise.
• Guest Node is still 22.15.0 on 2.14.0 — the 2.13.0/2.14.0 releases did not move the Node version either (relevant to compat: capture owner-authorized BrowserPod 2.12.1 Gateway evidence #6).

2. Stock Node 22.15.0 has it — this is a build deviation, not a version property

On stock Node v22.15.0 (installed via fnm), the exact same probe body runs node:sqlite successfully without any flag (only an ExperimentalWarning). So the failure is not a Node-22.15 characteristic and not a missing --experimental-sqlite flag; the vendor build deviates from stock.

3. Every client-side avenue is closed (checked one by one)

• nodeVersion boot option is dead code. The npm package is a 376-byte stub that imports https://rt.browserpod.io/<version>/browserpod.js; the shipped boot(e) in that bundle reads only apiKey, apiDomain, storageKey, rootImage, userImage. The nodeVersion declared in index.d.ts (and passed as "22" by our adapter) is never read. There is also exactly one guest image lineage — node22.ext2 per version directory; node24.ext2/node20.ext2 return empty (204).
• Flags/env cannot help — stock 22.15 needs no flag for node:sqlite (see 2), and the guest node parses no CLI flags anyway.
• Relaxing our preflight gate would be dishonest — node:sqlite is a real OpenClaw dependency in every tracked artifact: 2026.7.1-2 (8 dist modules, 43 DatabaseSync references, incl. engine-storage) and even the older-baseline target 2026.5.7 (engine-storage + sqlite-wal, 11 references).
• rootImage/userImage is not a realistic self-serve path — undocumented, and the Node engine is not a swappable binary inside the guest image (the vendor's own docs state native binaries only run if they provide a Wasm build for the proprietary toolchain).

Conclusion

The problem exists, ships in the latest vendor release, and is fixable only by Leaning Tech (compile/register the node:sqlite binding in their guest Node build — which their own process.versions already claims to contain) — or, on a different axis, by upstream OpenClaw making its SQLite dependency optional, which is not Clawsembly's call. Draft vendor report below.

---

Draft for the vendor filing (leaningtech/browserpod-meta), ready to submit

Title: Guest Node 22.15.0 reports versions.sqlite: "3.49.1" but node:sqlite fails with "No such binding: sqlite" (verified on 2.12.1 and 2.14.0)

Booting a pod (2.12.1 and 2.14.0 runtimes, arch: wasm32) and running require("node:sqlite") inside the guest throws No such binding: sqlite, and require("node:module").builtinModules does not include sqlite — while process.versions reports "sqlite": "3.49.1" and stock Node v22.15.0 runs node:sqlite out of the box (unflagged since 22.13). node:crypto works fine.

Repro inside any pod: node -e equivalent staged file with:
const { DatabaseSync } = require("node:sqlite"); new DatabaseSync(":memory:").exec("select 1");

Is the sqlite builtin intentionally excluded from the guest build? If so, could the process.versions metadata be corrected, and is there a roadmap for including it? Context: real-world workloads increasingly use node:sqlite for local storage (our use case: running the published openclaw npm package browser-locally; every current release of it calls DatabaseSync from its storage engine, so this is the single hard blocker after the Node-version baseline).

[yhay81]

Filed upstream with the vendor: leaningtech/browserpod-meta#11 (neutral observation + repro + the versions-metadata question). This issue stays open tracking our side; next state change is the vendor's response.