swarmail

<h1 align="center">
  <picture>
    <source media="(prefers-color-scheme: dark)" srcset="docs/assets/banner-dark.png">
    <img src="docs/assets/banner-light.png" alt="Swarmail" width="100%">
  </picture>
</h1>

<p align="center">
  <a href="https://github.com/bompus/swarmail/actions/workflows/ci.yml"><img src="https://github.com/bompus/swarmail/actions/workflows/ci.yml/badge.svg" alt="CI status"></a>
  <a href="https://github.com/bompus/swarmail/releases/latest"><img src="https://img.shields.io/github/v/release/bompus/swarmail" alt="Latest release"></a>
  <a href="LICENSE"><img src="https://img.shields.io/github/license/bompus/swarmail" alt="MIT license"></a>
  <a href="https://glama.ai/mcp/servers/bompus/swarmail"><img src="https://glama.ai/mcp/servers/bompus/swarmail/badges/score.svg" alt="Swarmail on Glama"></a>
</p>

Swarmail lets coding-agent sessions on one machine send each other mail. 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.

Find Swarmail on [Glama](https://glama.ai/mcp/servers/bompus/swarmail) and
[MCPRush](https://mcprush.com/aaron-queen/swarmail-mcp).

It is one Bun binary with a SQLite database, listening on `127.0.0.1:18765`.
There are no runtime dependencies.

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](docs/wake-bridges.md) 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.

<p align="center"><img src="docs/assets/demo.gif" alt="Claude Code and Cursor sessions on one repository. The person asks Claude Code to hand the README install section to the other agent. Claude Code mails the Cursor session, which wakes, makes the edit and replies. Claude Code wakes on the reply and checks the change." width="100%"></p>

If you are an AI agent reading this for your user, the prompt under
[Evaluate it with your agent](#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.

```text
I'm considering Swarmail (https://github.com/bompus/swarmail), local mail
between coding-agent sessions on one machine, 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 on this machine at once, 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 look at house-rules
(https://github.com/bompus/house-rules) and its opt-in swarmail modifier.
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](https://bun.sh) 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, and the
logon task starting a server at a real logon. If something fails there,
please open an issue.

1. Clone and install the dev tools:

   ```bash
   git clone https://github.com/bompus/swarmail.git
   cd swarmail
   bun install
   ```

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

   ```bash
   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:

   ```powershell
   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.

3. 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:

   ```bash
   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](packages/mcp-relay/README.md) forwards each request to the server
   from step 2 and installs nothing itself.

4. 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.

   ```bash
   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.

5. 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](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

| Command                                                           | What it does                                                                                                     |
| ----------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| `swarmail serve`                                                  | Run the server                                                                                                   |
| `swarmail who [repo]`                                             | Agent names, session titles and edit checkouts, live sessions first                                              |
| `swarmail inbox`, `send`, `search`                                | Read, send or search mail as this session                                                                        |
| `swarmail thread <id>`                                            | One thread's messages, oldest first