llm-cli-gateway 2.0.0 went out on 4 June 2026. npm now reports 2.0.0 as the latest version, and the public GitHub release carries the platform binaries, bundled installers, SHA256 checksums, release manifest, and Sigstore bundles.
The headline change is simple: production persistence no longer depends on better-sqlite3
. The gateway now uses Node's built-in node:sqlite
, behind a single adapter in src/sqlite-driver.ts
, and that one architectural change removes an entire class of install-time supply-chain risk from the consumer tree.
That matters because the recent 1.17.x work was not really about SQLite as a database. It was about the native-module install path around better-sqlite3
, specifically the prebuild-install
, tar-fs
, and tar-stream
chain. In 2.0.0 that chain is not patched, worked around, or hidden behind an advisory. It is absent from production installs. The release verification now asserts that consumers get no better-sqlite3
, no prebuild-install
, and no tar-stream
in the installed tree.
The cost is a real breaking change: Node >=24.4.0
is now required. That is not arbitrary. The gateway's persistence layer binds plain objects like { id: ... }
to @id
SQL placeholders, and Node 24.4 is the point where node:sqlite
has the bare named parameter behaviour this code relies on. The test suite pins that behaviour so future changes fail loudly rather than turning into quiet persistence bugs.
The adapter itself is intentionally small. openDatabase
, openReadOnly
, GatewayDatabase
, and GatewayStatement
are now the surface area, with flight-recorder.ts
and job-store.ts
using that surface instead of touching SQLite directly. The release security audit enforces that node:sqlite
is referenced only by the adapter, which keeps the persistence boundary clear and reviewable.
There is one security detail in the read-only path that I particularly like. queryRequests
now opens a dedicated read-only SQLite connection, so row mutations fail at the SQLite engine level with SQLITE_READONLY
. During review, one exception was found: VACUUM INTO
can create a new file even on a read-only connection. The adapter now rejects VACUUM
and VACUUM INTO
on read-only connections, including comment-prefixed and multi-statement forms. That is the sort of fix that looks small in code but matters in a release claim, because it keeps "read-only" from becoming mostly read-only.
2.0.0 also raises the standard for migration confidence. The repo now has cross-engine WAL crash-recovery fixtures in both directions: databases written by better-sqlite3
are opened through node:sqlite
, and the rollback direction is tested as well. That is a better claim than "the schema did not change". It proves the practical case users care about, namely that existing logs.db
and jobs databases survive the engine change.
The rest of the current product surface is still there, and it is worth remembering what that surface has become. llm-cli-gateway is now a single MCP endpoint for Claude Code, Codex, Gemini, Grok, and Mistral Vibe. It supports sync requests, durable async jobs, restart-safe result collection, job deduplication, cancellation, real CLI session resume paths, cache-aware promptParts
, and gateway-managed git worktrees for isolated multi-agent workflows.
The personal-appliance side has also filled out. There is streamable HTTP transport with bearer-token auth, doctor --json
, provider setup snippets, Docker fallback, and release bundles for Windows, macOS, and Linux. The GitHub release assets for 2.0.0 include platform binaries, platform bundles, SHA256SUMS
, release-manifest.json
, and Sigstore signature bundles for verification.
The result is a cleaner distribution story. npm publishes use provenance through GitHub Actions. GitHub release installer artifacts are signed. The production dependency graph is smaller. Native SQLite is gone from consumer installs because SQLite is now supplied by Node itself. The release is not flashy, but it is a serious hardening release: fewer moving parts, fewer install scripts, a narrower persistence boundary, and stronger evidence around upgrade and rollback behaviour.
Links: