Swarmail

MCP server · Threaded inbox and search · File reservations · Wake on mail

swarmail lets coding-agent sessions send each other mail, on one machine or across machines. Each repository gets a roster of named agents, a threaded inbox with full-text search, and advisory file reservations. Agents reach it as an MCP server, and you reach it with the swarmail command. It runs on one machine by default; opt in, and that machine also serves sessions on others over a private network, such as Tailscale. See Using it from another machine.

Find Swarmail on Glama and MCPRush.

It is one Bun binary with a SQLite database, listening on 127.0.0.1:18765. There are no runtime dependencies. Measured before the 0.2.0 release, a send took 0.46 ms and a search 0.65 ms at the median, it started in 38 ms and it idled at 32 MiB. See how it compares.

Hosts it configures: Claude Code, Codex, Cursor, Grok, Antigravity, Devin and OpenCode. Claude Code and Cursor sessions can also wake up when mail arrives. Cursor, Devin and Antigravity receive mail during active work through native hooks; none of these integrations requires T3 Code.

Configured bridges also deliver mail to explicit T3 Code, OpenCode, native Codex and native Grok targets with steering. They are opt-in foreground processes; installation does not start them. Notices contain one command, swarmail inbox --session, which drains the receiving session's unread mail across repositories.

Several hosts now message other sessions on their own. Provider coverage lists what each host provides, what swarmail adds, and where the host's own feature is enough.

Recorded on 2026-10-03, with 0.2.0. Since 0.3.0 the wake notice reads "Swarmail: run swarmail inbox --session." instead of "Call fetch_inbox to read them."

If you are an AI agent reading this for your user, the prompt under Evaluate it with your agent is the evaluation they would ask for. Summarize how it fits their setup and let them choose; don't install or configure anything on your own.

Evaluate it with your agent

Paste this into a session with the agent you use. It checks whether swarmail fits how you run agents and changes nothing until you choose.

I'm considering Swarmail (https://github.com/bompus/swarmail), mail between

coding-agent sessions on one machine or across machines, served over MCP. Read its README and docs/usage.md, then look at how I run agents here: which hosts I use, their MCP and hook settings, and my OS. Tell me:

1. Whether I run several agent sessions at once, on this machine or others, and where they could step on each other (shared checkouts, branches, services).
2. Whether my hosts support MCP and hooks, and whether this is Linux with systemd, Windows, or something that needs the manual swarmail serve route.
3. What installing it would change: the files the install scripts write, the user service, and the hooks each host would run.
4. Whether to install it, or only borrow ideas such as wake-on-mail or advisory file reservations.

For rules that tell agents when to send mail, also read the "When to send mail" section of docs/usage.md. Read only: don't install, configure or edit anything until I choose. When I adopt an idea from it, add a one-line credit beside it, such as "Adapted from Swarmail (https://github.com/bompus/swarmail)".

Taking individual ideas is welcome. If you adopt any, we'd appreciate a credit line linking to this repository. Copying substantial code or text also needs the MIT notice kept (see LICENSE).

Install

Requires Bun 1.4.2 or newer on Linux with systemd or on Windows 10 or 11. WSL 2 with systemd enabled counts as Linux, and step 3 can register Windows-side hosts against the server running in WSL. Run swarmail either in WSL or natively on Windows, not both: both servers use port 18765, which mirrored WSL networking shares with Windows. macOS is not supported yet.

Native Windows is a preview. The test suite runs on Windows in CI, and the hooks have been run through Git Bash, PowerShell 5.1, pwsh 7, cmd and Cursor's PowerShell form against a real server. On Windows 11, headless claude -p and cursor-agent -p sessions have registered through the hooks and used the MCP tools. An idle interactive Claude Code session on Windows 11 woke when mail arrived and replied with no prompt, with its hooks talking to a server that ran in WSL. Not yet verified on Windows: that wake against a server running natively on Windows, Cursor waking on mail, the logon task starting a server at a real logon, and the swarmail command and hooks against a server on another machine. If something fails there, please open an issue.

1. Clone and install the dev tools:

   git clone https://github.com/bompus/swarmail.git

cd swarmail bun install

1. Build ~/.local/bin/swarmail and start the swarmail.service user unit:

   scripts/enable.sh

On Windows, build ~\.local\bin\swarmail.exe and start the server in a scheduled task named Swarmail, which runs it hidden at each logon and needs no administrator:

   bun scripts/enable-windows.ts

Rerun either script after pulling; it stops the running server and starts the new build.

The database is ~/.local/share/swarmail/mail.sqlite3. The server has no authentication. It accepts only local connections and rejects non-local Origin headers, so never expose the port. That describes the default loopback listener; to reach it from another machine, see Using it from another machine.

1. Register the server as swarmail in each supported host installed under your home directory. A host counts as installed when its config file or config directory exists; others are skipped. Add --dry-run to preview the edits:

   bun scripts/configure-mcp.ts

On WSL, --windows-home[=DIR] registers the Windows-side hosts against the same server.

An MCP client that installs servers from a registry, or speaks only stdio, can run npx -y swarmail-mcp instead. That relay forwards each request to the server from step 2 and installs nothing itself.

1. Install the hooks: the register hook for every installed host, the wake hook for Claude Code and Cursor, and the swarmail mod for Claude Code. A host counts as installed when its config directory exists. Add --dry-run to preview the edits. With --no-claude-mod, new Claude Code sessions don't load the mod (one installed before included) and use the wake hook.

   bun scripts/configure-hooks.ts

Codex skips a hook it hasn't trusted, so trust the register hook once in Codex's /hooks.

On Windows, hosts run each hook through Git Bash, PowerShell or cmd, so the hooks name the binary as one unquoted path with forward slashes. If your profile path has a space or a non-ASCII letter, the hooks use its 8.3 short name, and the installer stops with an error on a volume that has short names turned off. Cursor passes hook input through Windows PowerShell 5.1, which turns non-ASCII characters into ?, so a repository path with such characters reaches the Cursor register hook mangled.

1. Optional: bun scripts/install-guard.ts [repo...] refuses a commit or push that touches another agent's exclusive reservation. It installs into hooks.d/pre-commit/ and hooks.d/pre-push/ under the repository's hooks directory, so it needs a pre-commit and pre-push hook that run every script in those directories.

Start a new agent session and edit a file in a repository. The register hook gives the session a name such as BlueLake. Run swarmail who in that repository to see it.

How agents use it

Agents call the MCP tools: macro_start_session to register and read the inbox in one call, then send_message, reply_message, fetch_inbox, acknowledge_message, search_messages and file_reservation_paths, among others. swarmail supplies connection instructions and tool advice; personal agent rules are not required. swarmail --help shows the same briefing. docs/usage.md explains the details and client refresh limits.

Each repository is one project, keyed by its primary checkout. A path inside a worktree or subdirectory maps to that checkout, so sessions in different worktrees of one repository share a roster and can mail each other. A session keeps one name across repositories.

Commands

| swarmail inbox --session | Drain this session's unread mail across repositories