Best Terminal Email Client: aerc, NeoMutt and Friends

The short answer
For most developers in 2026 the best terminal email client is aerc — modern, IMAP and notmuch backends, HTML rendering and OAuth built in. NeoMutt suits power users; Himalaya suits scripting. No mature terminal client is AI-native yet; for AI triage and drafting you script an API or use a graphical AI client.
The best terminal email client for most people is aerc; NeoMutt for power, Himalaya for scripting. Setup, HTML, Gmail OAuth and where each hurts.
On this page
- 01The short answer: which terminal email client should you pick?
- 02How we compared these terminal clients
- 03Terminal email client comparison table
- 04How to read this shortlist
- 05aerc: the best terminal email client for most people
- 06NeoMutt: the power user's pick
- 07Mutt: the original, still stable
- 08Himalaya: for scripting, not sitting in a UI
- 09meli: the modern Rust TUI
- 10notmuch and alot: the tag-based mail workflow
- 11Where AI Emaily fits — and where it does not
- 12How to choose for your situation
- 13Frequently asked questions
The best terminal email client depends on how much setup you will trade for control, but for most developers the answer in 2026 is aerc — a modern text-mode client that handles IMAP, notmuch, HTML mail and Gmail OAuth without the years of dotfile archaeology the older clients ask for. NeoMutt and Mutt are still the power tools. Himalaya and meli are the newer options. This guide covers each: what it costs to set up, how it renders HTML, how it handles OAuth, and where it still hurts.
One thing up front, because it shapes the whole page: AI Emaily has no terminal client. We build AI Emaily, and it is a web and desktop app, not a TUI — there is no Linux desktop build and nothing that runs in a text console. So this is not a post where we quietly rank ourselves first. If you want a keyboard-driven mail client inside your terminal, the tools below are the answer, and we say where our API and MCP server fit for the narrower job of scripting email — near the end, once the real options are covered.
A terminal mail client is a text-mode program you drive from the keyboard: no mouse, no web view, fast over SSH, and scriptable in ways a graphical client is not. The trade is real work up front — config files, an external OAuth helper for Gmail, and often a separate tool to fetch and index mail. The payoff is a client that launches instantly, uses almost no memory, and bends to exactly the workflow you want.
The short answer: which terminal email client should you pick?#
If you want one recommendation, start with aerc. It is the terminal client that asks the least of you to get working and still scales up to threading, multiple accounts and scripting. NeoMutt is the choice when you want maximum configurability and do not mind the learning curve. The rest are about matching a tool to a specific habit — a scripting workflow, a tag-first mindset, or a preference for Rust.
- aerc — best for most people. A modern text-mode client with sane defaults, IMAP/Maildir/notmuch/JMAP backends, built-in HTML viewing and OAuth support. Written in Go, free and open source.
- NeoMutt — best for power users. A maintained fork of Mutt with a sidebar, notmuch and NNTP, and configuration for nearly everything. Deep, but you earn it.
- Mutt — best if you want the original and a minimal, stable base. Pairs classically with notmuch for search and tagging.
- Himalaya — best for scripting. A command-line email manager (not a TUI) in Rust; you run shell commands instead of living in an interface.
- meli — best if you want a modern Rust client. Actively developed, with Maildir, mbox, notmuch, IMAP and JMAP.
- notmuch + alot — best for a tag-based, search-first workflow rather than folders.
Try aerc first, then reach for the others
How we compared these terminal clients#
We did not score these on a bench of a dozen installs and a stopwatch — that is the kind of claim that is easy to write and impossible to stand behind. Instead we compared them on the capability dimensions that actually decide a terminal mail setup, each checked against the project's own documentation. Those dimensions are the columns in the table below, and they are where these clients genuinely differ.
- Setup cost — how much config, and how many helper tools, before you can read mail.
- Backends — IMAP, Maildir, notmuch, JMAP, mbox; and whether the client fetches mail itself or expects a separate sync tool.
- HTML rendering — whether it can show HTML mail, and how (in-client versus handing off to an external viewer).
- Gmail OAuth — whether it speaks OAUTHBEARER/XOAUTH2, and how you supply the token.
- Where it hurts — the honest rough edge each one carries.
Gmail and Microsoft OAuth is the sharp edge (as of 2026)
Terminal email client comparison table#
| Client | Type | Backends | HTML mail | How you supply Gmail OAuth | Best for |
|---|---|---|---|---|---|
| aerc | Modern TUI (Go) | IMAP, Maildir, notmuch, mbox, JMAP | In-client, via an embedded terminal browser | OAUTHBEARER/XOAUTH2 built in, with a token command | Most developers |
| NeoMutt | TUI (C), Mutt fork | IMAP, POP, Maildir, mbox, notmuch, NNTP | External viewer via mailcap (e.g. w3m) | OAUTHBEARER/XOAUTH2 with a token-refresh helper | Power users who configure everything |
| Mutt | TUI (C) | IMAP, POP, Maildir, mbox | External viewer via mailcap | OAUTHBEARER/XOAUTH2 via mutt_oauth2.py | Purists and minimal, stable setups |
| Himalaya | CLI, not a TUI (Rust) | IMAP, SMTP, Maildir, JMAP, Gmail & Graph APIs | Plain text / limited | OAuth 2.0 via an external helper | Scripting and automation |
| meli | Modern TUI (Rust) | IMAP, Maildir, mbox, notmuch, JMAP | External filter | Token supplied via a command | A modern Rust client |
| notmuch + alot | Indexer + Python TUI frontend | Local Maildir (fetch with a separate tool) | External viewer | Handled by your sync tool (e.g. mbsync) | Tag- and search-first workflows |
How to read this shortlist#
The table is roughly ordered by setup cost, not by quality. aerc sits at the top because it asks the least of you; NeoMutt and Mutt sit lower because they trade convenience for a configuration surface you control down to the keybinding. Himalaya is a different shape entirely — a command-line tool, not an interface — and meli is the newer Rust take on aerc's territory.
So pick by what you are optimizing for. Least friction points to aerc. Maximum control points to NeoMutt. A scripting-first goal points to Himalaya. A tag-and-search brain points to notmuch. None of these is wrong; they answer different questions.

aerc: the best terminal email client for most people#
aerc is the terminal client to try first. It is a modern TUI written in Go, and it does the most out of the box: IMAP, Maildir, notmuch, mbox and JMAP backends, HTML mail shown through an embedded terminal browser, an embedded terminal so you can reference another thread while you compose, and vim-style keybindings with an ex-style command line. The project describes itself as 100% free and open source software.
On authentication, aerc speaks OAUTHBEARER and XOAUTH2 directly, so a Gmail or Microsoft account connects with a token command rather than a pile of external glue. Where it hurts: it is younger than Mutt, so a few deep customizations that veterans expect are either missing or done differently, and its notmuch integration, while good, is not the fully tag-native experience of a purpose-built notmuch frontend. For most developers those are minor next to how quickly it gets you reading mail.
NeoMutt: the power user's pick#
NeoMutt is the choice when you want to configure everything. It is a maintained fork of Mutt, written in C, whose motto — 'Teaching an Old Dog New Tricks' — is honest about what it is: Mutt plus years of curated, documented patches. You get a sidebar (its sidebar work was accepted upstream into Mutt), notmuch integration, NNTP for newsgroups, status- and index-color, Lua scripting, and configuration for very nearly everything.
HTML mail is rendered by handing it to an external viewer through mailcap, typically a text browser like w3m. OAuth works through the same mechanism as Mutt — OAUTHBEARER/XOAUTH2 with an external token-refresh helper. Where it hurts: the configuration surface is enormous, and a working setup can mean hours in the manual and other people's dotfiles before mail flows the way you want. That depth is the point for the people who choose it, and overwhelming for the people who do not.
Mutt: the original, still stable#
Mutt is where terminal email largely started, and it is still maintained. If you want the smallest, most predictable base and are happy to add tools around it, Mutt is a fine foundation — many people run NeoMutt precisely because they wanted Mutt with more built in. It supports IMAP, POP, Maildir and mbox, renders HTML through mailcap and an external viewer, and handles Gmail with OAUTHBEARER/XOAUTH2 using the mutt_oauth2.py helper shipped in its contrib directory.
The classic pairing is Mutt with notmuch: let notmuch index and tag your mail, and use Mutt to read it. Where it hurts: out of the box it is spartan, and while its IMAP works, many people prefer to sync mail locally first with a tool like isync (mbsync). You will assemble more of the workflow yourself than with aerc — which is exactly why the people who like knowing what every piece does tend to stay.
Himalaya: for scripting, not sitting in a UI#
Himalaya is the odd one out here, and deliberately so: it is a command-line email manager, not a TUI. Written in Rust, it has no event loop and no interface to live in — its own docs put it plainly, that you interact with your emails using shell commands, in a stateless way. That makes it the natural pick when your goal is scripting and automation rather than a text-mode inbox.
It supports IMAP and SMTP, Maildir, JMAP, and Gmail and Microsoft Graph through their APIs, with OAuth 2.0 handled by an external helper. A separate himalaya-tui is in active development for people who do want an interface. Where it hurts: if you actually want to sit and read threads all day, a CLI is awkward compared with aerc or NeoMutt — that is what the companion TUI project is for. But for cron jobs, pipelines and one-off queries, calling himalaya from a script is cleaner than driving a full client.
meli: the modern Rust TUI#
meli is for people who want aerc's 'built today' sensibility with a different lineage. It is actively developed — the most recent release, v0.8.13, landed in January 2026, with work continuing since — and it aims for configurability and sane defaults for both new and power users of the terminal. Backends include Maildir, mbox, notmuch, IMAP and JMAP.
HTML mail is shown through an external filter, and you supply credentials, including OAuth tokens, through a command. Where it hurts: it is the least widely deployed of the clients here, so you will find fewer worked examples and community dotfiles than for Mutt or NeoMutt, and some rough edges come with a younger project. Check its current documentation for exact backend and auth support before you commit. If you like Rust and want something fresh, it is worth a look.
notmuch and alot: the tag-based mail workflow#
notmuch is not a mail client at all — it is a fast mail indexer built around search and tags rather than folders. You point it at a Maildir, it indexes everything, and then you query and tag from any of its frontends. That is the notmuch mail workflow: your mail is one big searchable store, and a 'folder' is just a saved search for a tag.
The frontends include the alot TUI (written in Python), Emacs's notmuch mode, and notmuch support inside aerc and NeoMutt, so you can adopt the model without abandoning your client. Because notmuch reads local mail, you pair it with a sync tool — isync (mbsync), OfflineIMAP or getmail — to fetch from IMAP first. Where it hurts: it is more moving parts than a single client, and the tag-first model is a genuine switch if you have always thought in folders. For heavy-search, high-volume inboxes it is the most powerful approach on this list.
Where AI Emaily fits — and where it does not#
Now the honest placement. AI Emaily is not a terminal client, and we are not going to pretend it is — there is no TUI, no ncurses interface, and no Linux desktop build. It runs in a browser and as downloadable Mac and Windows apps, with a native iOS app and an Android PWA. If your requirement is a text-mode mail reader in a terminal, stop here and pick aerc or NeoMutt. We build AI Emaily, and on that specific job the tools above beat us.
What a terminal-minded reader sometimes actually wants, though, is not the text UI itself but what it enables: scripting. Reading, triaging, drafting and sending mail from a pipeline, a cron job or an agent, without clicking. That is a different need, and it is the one where we have something to offer. AI Emaily exposes a documented API and an MCP server, so your own scripts — or an AI agent you run — can list threads, search, draft and send, using the same approval gate and audit trail the app uses. The drafting voice comes from a Context brain and per-client profiles you set, not from scraping your old mail.
So: for a terminal UI, use one of the clients above. For AI triage and drafting you can drive programmatically, the API (/api-docs) and the MCP server (/mcp) are the bridge, and the assistant itself is at /features/ai-email-assistant. It is a paid product with a 7-day free trial (card required, nothing charged if you cancel before day seven) — there is no free tier. The overview is on the homepage (/) and current plans are at /pricing.
Disclosure, plainly
How to choose for your situation#
The decision comes down to what you are optimizing for, not to a single winner. Match your main constraint to a tool and you will avoid the most common mistake in terminal email — reaching straight for the deepest client and giving up before mail arrives.
| If you... | Pick | Because |
|---|---|---|
| want the least setup and a modern feel | aerc | Sane defaults, built-in OAuth and in-client HTML viewing |
| want to configure every keybinding and hook | NeoMutt | The deepest, most documented configuration surface |
| want a minimal, rock-stable base | Mutt (+ notmuch) | The original — small, predictable, battle-tested |
| want to script email, not live in a UI | Himalaya | A stateless CLI you call from shell scripts |
| want a modern client written in Rust | meli | Actively developed TUI with modern backends |
| think in tags and search, not folders | notmuch (+ alot) | Fast indexed search and tagging as the core model |
| want AI triage or drafting you can script | AI Emaily API/MCP | Programmatic access — not a terminal UI |
Read that last row honestly: it is there because 'is there an AI email client for the terminal?' is a real question people bring to this topic, and the truthful answer is no mature AI-native TUI exists yet. If AI is what you are after, you either script it against an API or use a graphical AI client — the terminal clients above do not do it, and neither pretends to.
Whichever you choose, budget a couple of hours for the first setup, especially the OAuth step, and keep a working reference config to copy from. Terminal email rewards the time once — after that it is the fastest, lightest inbox you will use.
Frequently asked questions#
The questions people ask most when choosing a command line email reader in 2026 — on which tool wins, how Gmail OAuth works, and whether AI has reached the terminal yet.
Frequently asked
See it in AI Emaily
Keep reading
Sources

Written by
Nafiul HasanNafiul Hasan is an entrepreneur and AI automation system builder with 10+ years of experience turning messy, manual workflows into reliable automated systems. He designs and ships AI enterprise solutions end-to-end — the agent logic, the data plumbing, and the product people actually use — and founded AI Emaily to give busy professionals their attention back. He writes here from the builder's seat: what works, what breaks, and how to put AI to work without giving up control.