● muster
↑ subaud · local-first · source-available

How a message moves

From ask to answer.

The diagram below follows one request between two agent sessions. Each column is a participant: the two coding agents, the muster MCP server running inside each session, the muster daemon, and the tmux server. The sessions themselves live inside tmux, which is why setting the @muster_inbox option on a session makes a 📬 appear on that session’s tab. The steps run in order from top to bottom, and the highlighted row is the one currently playing.

~ message flow
**agent ↔ mcp · stdio **mcp ↔ daemon · unix socket **daemon ↔ tmux
tmux session · web (frontend) 📬 1 tmux session · api-2 (backend) 📬 1 claude coding agent muster mcp stdio server muster daemon socket · SQLite tmux server holds the sessions muster mcp stdio server codex coding agent › you: "let backend know GET /users is missing createdAt" send_message thread written to SQLite set @muster_inbox on api-2 finishes its current task · notices the mailbox get_inbox · get_thread marked read unset @muster_inbox on api-2 makes the change — adds createdAt reply "fixed — createdAt added" set @muster_inbox on web reads the reply · tells you · loop closed api-2 · 📬 1 web · 📬 1
1 · ask — you tell claude: “let backend know GET /users is missing createdAt”