4.9.2 - a clock step, a stderr warning, and a fresh Windows install

Three faults that could make a working vault look or become locked are closed, and a fresh Windows machine now gets told the one thing it is missing.

Like 4.9.1, this closes potential errors for anyone using Compartment through the Hermes MCP catalog entry or the Claude Desktop extension, where these failures surfaced as memory tools abruptly reporting the vault locked, or as a first setup that would not finish.

A stepped system clock can no longer relock a vault

The credential that keeps a vault unlocked between processes is sealed under a key bound to this boot, this user and this machine. The boot part came straight from the kernel, and the kernels do not keep it fixed: Linux derives btime and macOS derives kern.boottime from the wall clock, so stepping the clock moves the reported boot time by the size of the step. NTP does exactly that early on freshly booted machines and after many a suspend/resume. A moved reading cannot rebuild the key the credential was sealed under, and the code that opens the credential deletes a file its key will not open - so one clock step relocked the vault for every process holding it open and destroyed the stored credential on its way out, until the passphrase was typed again. Reproduced directly: a three-second step was enough. The boot value is now pinned for the life of the boot in a marker beside the credential, exactly the way Windows has always pinned its own - the same first-value-wins record, the same tolerances, now on all three platforms. A real restart is still detected the reliable way, shrunk uptime, and still locks the vault as designed.

The panel no longer mistakes a warning for a locked vault

The panel asks the CLI for status and parsed the reply with stderr folded in, so anything a library said there landed after the JSON and spoiled the parse. onnxruntime's device discovery says something there on every call under Azure/Hyper-V Linux, so on such machines the panel reported a healthy, unlocked vault as locked with "could not read vault status". Only stdout is treated as the CLI's answer now, decoded so that trailing noise can never invalidate the payload, and that onnxruntime warning is silenced at the source.

A fresh Windows machine is told what it is missing

onnxruntime does not import on a Windows machine without the Microsoft Visual C++ runtime - a clean Windows 11 install has none - and the failure was a bare DLL load failed naming an internal module. The first compartment init on such a machine now names the actual remedy: install vc_redist.x64.exe from Microsoft, one small installer, no restart, and run the command again. Verified on a fresh Windows 11 VM: with the runtime absent the message appears, and after that one install every part of Compartment works.

And the 4.9.1 contract is now proven everywhere

The machine-identifier tests from 4.9.1 now run on every platform, including the Windows registry branch, so the rule behind that fix - a failed lookup must raise rather than answer with something else - is exercised on all three systems rather than only where the fault could be staged.

Upgrading

On a machine whose clock has not stepped since the credential was stored, the pinned value equals the stored one, so credentials from 4.9.1 and earlier keep working and nothing needs unlocking again.

Downloads

Artifact	For
Compartment-4.9.2.pkg	macOS, one click, with the optional menu bar utility
Compartment-4.9.2.dmg	macOS, drag to Applications
compartment-4.9.2-py3-none-any.whl	pip / offline installs, any OS
compartment-4.9.2.tar.gz	source distribution, packagers, air-gapped builds

Or, for the CLI and MCP server without the app:

pip install compartment