Ranking 7 Email CLIs for AI Agents in 2026

Part 2 of 3 in our 2026 field test of terminal email clients for AI agents. Part 1 lays out the criteria. Part 3 documents the install and execution path behind the results.

The bias, up front

We work on Broodnet CLI. It is one of the 7 tools in this ranking, and it ranks first. That is the conflict of interest every vendor-authored roundup ships with, and we are not going to pretend otherwise.

What we can do is be loud about method. Same sandbox, same mailbox shape, same criteria for all 7 tools. Every ranking claim here comes from running the tool against a live account, not from reading a features page and calling it research. Where we rank our own CLI first, the reasoning is in the text and the evidence trail is in Part 3.

The origin story matters too. We did not start from “email for AI agents is a good market.” We started from trying to wire existing email CLIs into agent workflows and hitting the same walls over and over: services that pretend to be IMAP servers, installs that want root in environments without root, config files that need templating before the first API call, send flows that assume a human at the terminal, and --json flags that change shape from command to command. Broodnet CLI is our answer to that pile. If we had found an existing tool that cleared those bars, we would have used it instead of building our own.

The real split in this ranking is simple: Broodnet CLI and Himalaya feel built for automation. Everything else feels adapted to it.

The ranking

Rank	Tool	Verdict
1	Broodnet CLI	Ours. Disclosed bias above. One-line npm install, env-var auth, structured output across the commands that matter, and a validated read-plus-send workflow.
2	Himalaya	Strong general-purpose CLI. One-line install, native IMAP and SMTP, solid performance, workable automation story. Loses points on hand-written config and inconsistent JSON shapes.
3	NeoMutt	The only TUI-era client in this set with a genuinely useful batch-send surface. Read flows still require the TUI.
4	nmail	A modern Alpine-shaped TUI. Active project, clear docs, good human-facing behavior, heavy Ubuntu install path. No non-interactive send path.
5	meli	Interesting architecture, fragile provisioning. Strong IMAP behavior, validated SMTP wiring, no practical non-interactive send path.
6	aerc	We proved the loop, but only by driving the embedded editor through tmux. Fine for humans, wrong shape for agents.
7	Alpine	Actively maintained, but entirely human-first. Scriptable in places, no structured output, no practical non-interactive read path for agents.

The two-tier story is worth stating plainly. If you want an agent-first tool, the choice is between Broodnet CLI and Himalaya. Everything below those two is a human-first project that you can force into agent use with enough patience. NeoMutt ranks where it does because it at least offers a clean batch-send path.

Comparison matrix

✓ = yes, ~ = partial, ✗ = no

Tool	Native IMAP	Native SMTP	One-line install	Non-interactive friendly	Structured output	Agent fit
Broodnet CLI	✓	✓	✓	✓	✓ JSON	✓
Himalaya	✓	✓	✓	~	~ JSON	~
NeoMutt	✓	✓	✓	~	✗	~
nmail	✓	✓	✗	✗	✗	~
meli	✓	✓	~	~	✗	~
aerc	✓	✓	✓	✗	✗	✗
Alpine	✓	✓	✓	~	✗	✗

Human-first tools can be made to work. That is different from saying they are a good default.

Verdicts, one per tool

1. Broodnet CLI

The one we make. Same test, same mailbox behavior, same evaluation criteria as the rest. The reason it ranks first is not mystery; it is that it clears the bar this series argues matters for agents.

This assessment is specifically about the 0.2.x line of Broodnet CLI, which is what we tested for this article. Future versions may add capabilities and change some of the tradeoffs described here.

npm install -g @broodnet/cli completes quickly, with no compile step and no native dependency chase. Authentication works cleanly through BROODNET_TOKEN=<your-token>, which means no first-run wizard and no state on disk if you do not want any. The send path takes the body on stdin and headers on flags. The --json output shape is consistent across the commands an agent would actually call.

The tradeoffs are equally clear. In the 0.2.x line we tested, Broodnet CLI is strong on the core read, send, open, and delete loop, but it does not yet give you folder support or plus-addressing style tag workflows such as something+tag@.... If your agent workflow depends on deep mailbox organization or tagged address patterns, that is a real gap today, not necessarily a permanent one.

If your agents need to email the public internet, choose a different tool. If they mostly receive from the internet and report back inside your account, this design is the point.

2. Himalaya

The strongest non-Broodnet tool in the set. It installs like a modern CLI and performs like one too.

The friction is in the config and the output shape. Himalaya wants a hand-written TOML file with separate account, IMAP, and SMTP sections. An agent can generate that file, but it is still setup work before the first useful command. The -o json flag also does not mean one consistent schema across commands, so your parser has to branch by subcommand.

Still, the fundamentals are strong. Native IMAP, native SMTP, solid speed, and a real non-interactive send path. For a general-purpose mail CLI that is not ours, this is the one we would point people to first.

Himalaya is the strongest general-purpose mail CLI in this set. It just asks a bit of time and attention on setup before it is ready to work for agents.

3. NeoMutt

The only TUI-era client in this ranking with a real batch-send surface, and that alone is why it lands above the rest of the human-first pack.

echo "body" | neomutt -F ~/.config/neomutt/neomuttrc \
  -s "subject" agent@broodnet.com

That send path worked. The message arrived with a proper envelope. NeoMutt even has the good manners to make the batch mode obvious in the command surface. The problem is the read side: there is no equivalent non-interactive inbox API, so a pure agent integration still has to pair it with something else.

If you already live in NeoMutt and want lightweight automation on top, this is a real option. If you are picking from scratch for an agent, the read-plus-send asymmetry is the dealbreaker.

4. nmail

A maintained Alpine-shaped TUI with healthier project prospects than Alpine itself. It looked good as a human-facing client. It did not look good as an agent tool.

There is no documented non-interactive send path. First-run behavior prompts for credentials in the terminal. You can automate around that with tmux if you are determined, but that is exactly the kind of workaround this series argues against.

The reason it appears in the article at all is that people looking for a long-term Alpine replacement should evaluate something alive. On that narrow question, nmail is interesting. On the agent question, it is still the wrong shape.

5. meli

Interesting architecture, fragile provisioning. Strong IMAP behavior, valid SMTP backend wiring, no real non-interactive send path.

This is the ranking entry where wording matters. We did not complete a full scripted send in the same way we did for the top tools. What we did validate was that the IMAP side behaved correctly, the mailbox rendered properly, and the SMTP shell accepted the envelope stages we could drive through its line-oriented interface. That is enough to confirm the backend wiring, not enough to elevate it into the top tier.

The second issue is provisioning. meli depends on a Rust toolchain that is recent enough, can drag you into vendored OpenSSL builds if you are not careful, and expects m4 on PATH. In a controlled environment that is fine. In an agent runtime, it is friction.

6. aerc

Validated end-to-end, and the way we had to do it is the whole problem.

aerc has no simple command-line send surface. To prove it worked, we launched it in tmux, opened compose mode, drove the embedded editor, and sent the message from inside the TUI. The message arrived. The conclusion is not “great, automation achieved.” The conclusion is that we had to script a curses app through another terminal layer just to get one send through.

One keybinding change upstream and the whole thing breaks silently. That is not a serious default integration story for agents.

7. Alpine

Alpine is the successor to Pine, the University of Washington mail client that was standard-issue for a generation of sysadmins and academics. UW released Alpine as open-source in 2006, then stepped back from development in 2008. A community fork called re-alpine bridged the gap through 2012. Since 2013, Eduardo Chappa — a former UW developer — has been the sole maintainer, distributing releases at alpineapp.email, with development releases still shipping into 2026. One person, one tool, thirty-five years of lineage.

Alpine’s command surface is surprisingly capable. It can take a body on stdin, it can compose from the command line, and it extracts cleanly in locked-down environments. If this article were only about technical bring-up, Alpine would place higher.

But agent fitness is not about bring-up. Alpine has no structured output, no env-var auth, no non-interactive read path, and its config model is pinerc — a format that predates TOML, YAML, and JSON. It ranks last because the automation surface is not there, not because the project is abandoned.

Recommendations by use case

Broodnet CLI — You are building a new agent that needs a real mailbox, and your main constraint is that it should work in CI and in a sandboxed runner. Yes, we make it. The one-line install, env-var auth, and consistent structured output are exactly the properties we built it around after hitting the gaps the other tools kept hitting.

Himalaya — You want a general-purpose mail CLI you will also use yourself, against any IMAP/SMTP provider. Plan for TOML config as setup work and per-command output parsing logic.

NeoMutt — You are already used to NeoMutt. The batch-send path is clean enough to layer lightweight automation on top of your existing setup without switching tools. your agent might struggle with the output, but it can at least get mail out.

What’s next

If you want the provisioning details, Part 3 is the install diary. That is where the build mess, dependency friction, and automation dead ends live.

If you used the broodnet CLI and have feedback on the experience, hit us up at @broodnet or human@broodnet.com.