One hub for every machine: a shared-brain setup, and a "new" Claude Code plugin for the client side

[shanelord01]

Mempalace is awesome - but having it tied to one machine just never worked for me. I need to be able to access it from wherever I am... desktop, laptop or mobile - at home, in the office or in a cafe.

So I setup MemPalace as a shared-brain hub: one mempalace serve with Qdrant on a home server.

Now every Claude Code machine, the Claude apps and a Hermes bot read and write through it. This post
is what the setup looks like end to end, and a plugin I wrote for the part the official plugin
does not cover. Feedback welcome, especially from anyone running more than one agent against a hub.

The hub

The hub follows the remote-server guide, with one addition. It binds to loopback on a machine
with no open inbound ports and is reached through a Pangolin tunnel. In front of it sits a small
Caddy container built with caddy-jwt that checks a Pocket ID OAuth token on every request and
swaps it for the hub's static token. Claude Code, Claude Desktop, the mobile apps and claude.ai
all log in with a passkey, and the hub itself is unchanged. The full walkthrough, with a check
after each stage, is here:
https://github.com/shanelord01/claude-mempalace-sharedbrain/blob/main/docs/hub-setup.md

What the client side was missing

Reading the 3.11.0 source: the Claude Code plugin's Stop, SessionEnd and PreCompact hooks run
mempalace hook run from the local Python package, and the package finds a hub only through a
registry file on the hub's own machine. On a laptop whose only palace is a remote hub, those
hooks have nothing to save to. mempalace rules renders the shared-brain block for CLAUDE.md,
but it prints to stdout and needs the package installed. The shared-brain guide's section 5 and
7 (wire the protocol in, keep agents wakeable) were the parts I had to do by hand on every
machine, and they drifted.

The plugin

https://github.com/shanelord01/claude-mempalace-sharedbrain

It is the client half of the shared-brain guide for Claude Code, with no mempalace package on
the machine. It adds no protocol wording of its own. MemPalace's texts travel verbatim.

• Renders the canonical shared-brain block exactly as mempalace rules does (the template is
  vendored with its upstream commit and hash, and the CLI is used instead when it is present),
  and installs, checks or replaces it in place in ~/.claude/CLAUDE.md. Every session start
  reports whether the installed block is current, stale or missing.
• Composes the host:harness:project identity from the working directory.
• Keeps the inbox cursor per identity and shows it at session start.
• At session start, puts the inbox sweep in front of the model before the first prompt: the
  exact mempalace_event_list calls to make from the cursor, or the results when the hook has its
  own path to the hub.
• Wakes the session on coordination events. A chat session cannot run logstream watch, so when
  the user arms listening, each prompt triggers one sweep since the watch cursor for
  task.request, task.reply and patch.ready, excluding the identity's own events. Arming
  prints the announcement the protocol asks for, disarming the declared-idle statement.
• Stop and PreCompact hooks that work without the package: a checkpoint request every 15 human
  turns in MemPalace's own wording, and a pre-compaction snapshot handed back after compaction.
• Commands for the delegation loop (mempalace_task_create, wait, verify the sha256, ack, file
  the outcome), checkpoints (mempalace_checkpoint) and fleet state (mempalace_mesh_peers,
  /statusz).

By default the hooks hold no credential. The model's logged-in MCP server makes every hub call,
and the hooks only tell it which calls to make and when. Optionally the hooks can read the hub
themselves, with the hub's static token or, for a hub behind an OAuth login, the client
credentials grant with a confidential client per machine.

Install:

claude plugin marketplace add shanelord01/claude-mempalace-sharedbrain
claude plugin install mempalace-sharedbrain@shanelord01 --scope user
/mempalace-sharedbrain:setup

Why bother

Before this, a task addressed to one of my machines sat unacknowledged for ten days because no
session on it happened to check the inbox. The rules block in each CLAUDE.md was pasted by hand
and three machines were on three versions, one citing a drawer that no longer existed. One
install command per machine now puts the same block, the same identity rule and the same sweep
in front of every session, and an update is one more command.

Things I would like opinions on

• Identity. I moved every Claude Code machine to host:claude:<workspace> as the protocol
  says. That means one inbox per project per machine, and a requester has to know which project
  the worker is in or broadcast. If you run a fleet, how do you address a machine as a whole?
• mempalace_diary_write rejects an agent_name containing colons (sanitize_name allows word
  characters, space, dot, apostrophe and hyphen), so a host:harness:project identity cannot be
  a diary name as-is. The plugin writes the diary under the identity with colons replaced by
  underscores. Is there an intended convention for this?
• The wake check without a hook-side credential costs the model one tool call per prompt while
  armed. An mcp_tool hook would avoid that if its input could carry a cursor. Is there a
  better pattern?
• Windows: the hooks are bash plus python3. If anyone runs this under Git Bash, I would like to
  know whether python3 resolved.

MIT, tests included (tests/run.sh, a fake hub over HTTP, SSE and stdio).