Project releases

Ruflo 3.56.5 keeps live SQLite locks intact when checking memory encryption

Ruflo 3.56.4 and 3.56.5 harden helper CLI resolution and move a database header check into a bounded child process so the parent's SQLite locks survive.

GitHub activity: · Published:

Read the header, keep the locks

The parent never closes a raw descriptor on the live database; a short-lived child does the read.

Explanatory diagram · not live telemetry
Explanatory connectionsThe parent process holds SQLite's live locks. On non-Windows systems the encryption header check runs in a bounded child, so the parent's locks stay in place. The old in-process close path, which dropped those locks, is gone. Windows still reads in-process because its locks are per handle.Explanatory connectionsThe parent process holds SQLite's live locks. On non-Windows systems the encryption header check runs in a bounded child, so the parent's locks stay in place. The old in-process close path, which dropped those locks, is gone. Windows still reads in-process because its locks are per handle.

Parent holds database

Live SQLite handle and locks

Encryption header check

Cold open / status check

Bounded child read

Empty env, 5 s timeout, capped output

Old in-process close

Closed descriptor dropped locks

Parent locks kept

Same encrypted / plain result

What changed

Ruflo shipped two patch releases early on October 11. In 3.56.5, the memory graph writer stops dropping SQLite's own locks when it checks whether a database file is encrypted. Before the fix, it opened, read and closed the database file inside the same process. On POSIX systems, closing any descriptor for that file releases every advisory lock the process holds on it, including the lock held by SQLite's live connection.

On non-Windows systems, the 64-byte header is now read by a short-lived child process. It has an empty environment, a single bounded read, a five-second timeout and a capped output buffer. Windows still reads in-process, because its byte-range locks belong to each handle. The encrypted/plain classification is unchanged, and a failed read still counts as not encrypted. The maintainers note one extra Node process spawn per check, which happens on cold open and in the encryption-status tool.

This is a different problem from the 3.56.3 fix, which recovered provably stale lock files in the sql.js memory path. 3.56.5 concerns live POSIX locks on a native SQLite database file. It does not change stale-lock recovery.

Also in 3.56.4

  • Helper CLI resolution (PR #3990): signed hook and statusline helpers now resolve the Ruflo CLI from the helper's own install root, not the opened project. A project can therefore no longer supply the CLI those helpers run. The statusline also skips install paths that contain shell-active characters, instead of interpolating them into a shell command.
  • Plugin trust (release notes, #3948 and #3951): an all-zero placeholder registry trust anchor no longer vouches for plugins, and plugin upgrade no longer bypasses the install gate.
  • Community detection (PR #3977): the fallback Louvain clustering code now maintains community totals incrementally instead of rescanning every node. The release notes describe it as graph path search; the merged code changes community detection. The PR's own synthetic test asserts identical partitions and modularity to the old code. We did not reproduce its timings.

Get started

Use your existing Ruflo dependency workflow on Node >=20, in a disposable project. npm view should report 3.56.5. @claude-flow/cli, ruflo and claude-flow were all published at 3.56.5; no leaf package changed after 3.56.4.

Documentation-verified only. We did not install this release, execute these commands, run a workload or reproduce the maintainers' tests or SQLite behaviour.

npm view ruflo@3.56.5 version

These patches add no new MCP endpoint or skills setup. If you configured MCP for an earlier 3.56 release, that configuration is unchanged.

Use it today

If you run Ruflo memory on Linux or macOS with the native SQLite graph store, update through your normal dependency workflow, then open, write, close and reopen a disposable database. If you use the signed statusline or hook helpers, confirm they still report from your installed CLI after the update.

Experimental commentary — acceptance test

On Linux, the maintainers' test reads the kernel lock table (/proc/locks) before and after the header check while a WAL connection is open. Acceptance: the database file's shared lock is still listed afterwards. Limitation: the maintainers did not reproduce the reported WAL deletion end to end. Their test proves the lock behaviour, not that data loss is prevented in every workload.

Limits and verification

  • Sources: both release notes, merged PR diffs, the pinned graph-edge-writer.ts at commit 1ab960c, and the npm registry records. Separately, the 3.56.5 CLI tarball was inspected and contains the child-process header reader, and the ruflo and claude-flow packages reference that CLI version. That is package-content evidence, not an end-to-end workload test.
  • The helper hardening closes one untrusted-search-path route. It does not show that every helper or security boundary is safe.
  • The release workflow's witness signature is derived from public commits. It is not an independent platform provenance attestation.
  • The newsroom ran no benchmark, workload, maintainer test suite or SQLite recovery reproduction.

Read the original on Ruflo v3.56.5 release

v3.56.5 / PR #4044

Ruflo repository

Back to the newsroom