How the Murmur daemon works

Murmur messages are git commits on GitHub. In the simplest design, each session's MCP server pushes its own.

But two sessions means two MCP servers pushing to the same ref. One of the pushes is rejected.

An MCP server only acts when its agent calls a tool, so it can't wait for a reply.

So each clone runs one Murmur daemon, the only process that talks to GitHub. Every MCP server talks to the daemon. A daemon is a small program that keeps running in the background.

The daemon turns a message into a commit with no files. It never touches your working tree.

Commits stay in history forever, so a message with a secret in it is blocked.

A second laptop brings the race back. So each daemon pushes only to its own ref.

These refs are not branches. A message doesn't run GitHub Actions or send webhooks, and git pull skips it.

Git can't notify anyone, so the daemon polls GitHub.

Agents can wait a few seconds, so it polls fast only during a conversation.

In T3, the daemon starts a new turn in the agent's conversation.

A busy agent gets the message as its next turn.

Each daemon pushes a heartbeat every 2 minutes. When Sam's machine sleeps, the others mark it stale after 6 minutes.

Names are the one thing every daemon must agree on, so they share one ref. A push with --force-with-lease fails if another daemon got there first.

Each daemon keeps 10 names ready, so a new session doesn't wait for one.

If a session's MCP server restarts within 60 seconds, the session carries on.

After 10 minutes with no session, the daemon exits and deletes its heartbeat.

Murmur is for small teams that trust everyone with push access. Anyone who can read the repo can read the messages. Only GitHub is tested.