Repository navigation
4.11.0 - the menu bar opens at once, and one rule for what to store
The menu bar panel no longer opens your vault every time you click it, every agent now gets the same, narrower rule for what to store, and a race that could lose a memory while the vault was being opened is fixed.
The menu bar
Every click on the icon used to start two fresh Compartment programs, compartment status and then compartment recent. Each one loaded Python and decrypted the whole vault, thousands of starting memories included, to show a count and five lines. The second one then rewrote the vault file on its way out, which made every running agent's server read the whole vault again at its next memory call. On a test vault of 6,664 memories that took about 2.2 seconds before the panel could appear, and a read that failed or ran slow was shown as "locked".
Now:
- The panel opens at once from what it last knew, then refreshes in the background and updates in place when fresh numbers arrive. Measured on the same vault: 129 ms from the request to the panel on screen, with no vault read in between.
- It refreshes only when something changed. It compares the modification times of the vault file, its settings, the stored unlock and the date, and when none of them moved it reads nothing.
- When it does read, one helper process does the reading and keeps the vault open while you use the panel. Memories that agents add are read on their own, in about 20 ms, instead of decrypting the whole vault again. Only a vault file that was rewritten is read in full, about 0.6 seconds on the test vault.
- Agent settings (Claude Code, Claude Desktop, Hermes, OpenClaw) are re-read only when one of those files changes.
- Looking never changes the lock. The panel shows "locked" only when there is no stored unlock, or the stored one no longer opens the vault. A read that fails keeps the last known state and says what went wrong, and before the first read the panel says "checking" instead of guessing. The vault locks and unlocks only when something asks it to: the Lock and Unlock buttons,
compartment lockandcompartment unlock, an agent'smemory_lockcall, or a restart. Lock stays on the panel while the state is unknown, because locking is safe either way. - Looking never writes. The helper opens the vault read-only: no rewrite, no expiry sweep and no audit entry, the same rule the dashboard keeps.
The helper talks to the panel over its own pipes, with no socket and no port. While it runs it holds the key, as each agent's MCP server does. It exits after ten idle minutes, lets go of the key within 30 seconds of a compartment lock typed in a terminal, and is stopped before the Lock button clears the stored unlock. On the test vault it used about 62 MB while open. SECURITY.md has the details.
The tray on Windows and the panel window on Linux use the same code.
What to store
Every storage instruction Compartment gives agents now reads the same: the MCP handshake that Claude Code, Codex, Claude Desktop and other MCP clients receive, the memory_store tool, the CLAUDE.md block, the Hermes provider, the /compartmentalize skill, GEMINI.md and the Oh My Pi tool.
STORE anything worth referencing again in future work: names, addresses, contacts, account IDs, passwords, API keys and other credentials, lasting file locations and configuration, preferences, and every durable fact or decision reached. Not transient chatter, one-off trivia, things freely available on the internet, or the working details of a task in progress, such as run results, errors, log contents and temporary paths or settings.
The new part is the last clause: run results, errors, logs and temporary paths from work in progress stay out of long-term memory.
A memory stored while the vault was opening could be lost
Opening a vault reads the file, decrypts it, and then records the file's size and time as the version it holds. A memory another process appended in between was counted as read when it never was. The open's own tidy-up, which rewrites the file whenever it replays pending entries, could then write the file back without that memory. An open that did not rewrite believed it was current, and its next write took a journal position the other process had already used, which left a vault that failed its integrity check on every later open. The old menu bar opened the vault twice per click, so a click at the moment an agent stored something could trigger it; agents and the command line could as well.
The version is now recorded before the file is read. An open that finds the file changed underneath it reads it again, and a copy that has fallen behind is refused with the existing "reopen and retry" error instead of writing over newer data.
Upgrading
pip install --upgrade compartment, or compartment update, which also restarts the menu bar app. Then run this once:
compartment integrate --refreshIt updates the copies of the instructions that earlier installs wrote into your agents' own files (the CLAUDE.md block, the /compartmentalize skill, the Hermes plugin), only where they exist, and changes nothing else: no capture hook, no registrations. From this version on, compartment update runs it for you. Restart your agents so they receive the new instructions. Vaults open unchanged. The app bundle is updated by the installers below.
Downloads
| Artifact | For |
|---|---|
Compartment-4.11.0.pkg |
macOS, one click, with the optional menu bar utility |
Compartment-4.11.0.dmg |
macOS, drag to Applications |
compartment-4.11.0-py3-none-any.whl |
pip / offline installs, any OS |
compartment-4.11.0.tar.gz |
source distribution, packagers, air-gapped builds |
pip install compartment