4.9.1 - a vault no longer relocks itself when a system lookup fails

An unlock credential is no longer thrown away when the operating system cannot answer a question about the machine it is running on.

Among the places this matters most are the Hermes MCP catalog entry and the Claude Desktop extension: a relock there surfaces as every memory tool abruptly reporting the vault locked mid-session, so this release closes those potential errors for anyone using Compartment through either of them.

Why a vault could relock on its own

The credential that keeps a vault unlocked between processes is sealed under a key bound to this boot, this user and this machine. The machine part came from the platform's own identifier: IOPlatformUUID via ioreg on macOS, /etc/machine-id on Linux, MachineGuid in the registry on Windows. When that lookup failed, for any reason at all, Compartment quietly used the hostname instead. A substituted value cannot rebuild a key sealed under the real one, and the code that opens the credential cannot tell a key that will not open the file from a credential that nothing can open, so it deleted the file. The vault relocked for every process holding it open, and stayed locked after the original fault had cleared, until the passphrase was typed again.

On macOS the lookup shells out to ioreg on every vault open under a five second bound, so a busy machine was enough on its own. On Linux an empty /etc/machine-id, which is systemd's generate-on-first-boot state and ships that way in several container base images, was read as an identifier of "" instead of falling through to /var/lib/dbus/machine-id and then to the hostname. On Windows any failed registry read did the same thing.

What changed

A lookup that fails now raises instead of answering with something else, which is what the boot-time half of the same key has always done. It surfaces as a lock error for the single call that hit it and leaves the stored credential alone, so the vault opens normally again the moment the fault clears. Where a system genuinely has no platform identifier, a container with no machine-id file being the usual case, the documented hostname fallback still applies: there the hostname is the stable answer rather than a substitute for one.

The identifier is now also pinned for the life of the boot, in a 0600 marker beside the credential, so every process of a boot agrees on one value and no later hiccup can move it. That takes ioreg off the vault-open path after the first call, and it holds the hostname steady on the systems that do fall back to it, where a network rename was previously enough to re-key the credential by itself.

Upgrading

On any machine where the lookup works, the value is unchanged, so credentials stored by 4.9.0 and earlier keep working and nothing needs unlocking again.

Downloads

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

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

pip install compartment