Caution
Himalaya TUI is in active development and currently shipped as v0.x.x. Expect breaking changes between releases until stabilization.
- Remote backend support: IMAP, SMTP, JMAP
- Local (filesystem) backends support: Maildir specs, m2dir specs
- Simple auth support for IMAP/SMTP: anonymous, login, plain, oauthbearer, xoauth2, scram-sha-256
- HTTP auth support for JMAP: basic, bearer
- TLS support:
- Rustls with ring crypto
- Rustls with aws crypto (requires
rustls-awsfeature) - Native TLS (requires
native-tlsfeature)
- Discovery support:
- Three-pane layout built on ratatui: mailboxes, envelopes, message body or composer
- In-app composer powered by edtui with system-editor handoff (
Alt-e) - Color themes: built-in presets plus per-field overrides in the config (see Theming)
- Shared configuration file with
himalaya: same[accounts.<name>]blocks load on both binaries (see Configuration)
Tip
Himalaya TUI is written in Rust and uses cargo features to gate backend support. The default feature set is declared in Cargo.toml.
Himalaya TUI is not yet released, therefore the only way to get a pre-built binary is to check out the releases GitHub workflow and look for the Artifacts section.
Note
Such binaries are built with the default cargo features. If you need specific features, please use another installation method.
cargo install --locked --git https://github.com/pimalaya/himalaya-tui.git
With only IMAP+SMTP support:
cargo install --locked --git https://github.com/pimalaya/himalaya-tui.git \
--no-default-features \
--features imap,smtp,rustls-ring
If you have the Flakes feature enabled:
nix profile install github:pimalaya/himalaya-tui
Or run without installing:
nix run github:pimalaya/himalaya-tui
git clone https://github.com/pimalaya/himalaya-tui
cd himalaya-tui
nix run
Run himalaya-tui. With no configuration file on disk the wizard prompts for an email address, a server URL or a bare domain, runs provider discovery, asks for SASL or HTTP credentials, then keeps the resulting account in memory for that session only (the TUI does not write to disk).
A persistent configuration is loaded from the first valid path among:
$XDG_CONFIG_HOME/himalaya/config.toml$HOME/.config/himalaya/config.toml$HOME/.himalayarc
These are the same paths the himalaya CLI looks at: one TOML file backs both binaries, starting from himalaya CLI v2. TUI-only fields and CLI-only sections coexist without errors. See config.sample.toml for a documented template.
Warning
A himalaya CLI v1 configuration file is not compatible with himalaya TUI: the v1 schema differs from the v2 one shared with the TUI. Upgrade the CLI to v2 (or rewrite the file using config.sample.toml) before pointing the TUI at it.
Override the path with -c <PATH> or HIMALAYA_CONFIG=<PATH>; multiple paths can be passed at once, separated by :. The first one is the base and the rest are deep-merged on top.
Pass --no-config to ignore both, even when a file is present: useful for testing another account in memory without exposing stored credentials.
The TUI uses named ANSI colors by default, so the rendering inherits the colors of your terminal palette. Pick a preset and/or override individual fields in the [theme] block of your config (full reference in config.sample.toml):
[theme]
preset = "dracula-dark"
[theme.cursor]
fg = "magenta"
bg = "#222"
mod = ["bold", "italic"]Color values accept named ANSI ("blue", "dark-gray", …), hex ("#ff8800"), 256-color indices ("33"), or "reset" for the terminal default. mod is a list of bold, dim, italic, underlined, slow-blink, rapid-blink, reversed, hidden, crossed-out.
Overrides are merged on top of the preset: any field you leave out keeps the preset value, so you can change just one attribute (e.g. only the cursor fg) and inherit the rest. Themable elements: header, status-bar, border-active, border-inactive, dialog-border, cursor, mailbox-current, envelope-header, envelope-seen, envelope-unread, message-body, compose-text, compose-cursor, compose-selection.
Presets live as plain Rust files under src/tui/theme and are shipped with the binary; pull requests adding new presets are welcome (see CONTRIBUTING.md).
Top-level navigation, supporting Vim and Emacs keybinds:
| Keybind | Action |
|---|---|
Tab |
Cycle panel |
↓, j, Ctrl-n |
Next item |
↑, k, Ctrl-p |
Previous item |
PageDown, Ctrl-d, Ctrl-v |
Next page |
PageUp, Ctrl-u, Alt-v |
Previous page |
Enter |
Select |
Esc, q, Ctrl-g |
Close panel / dialog / quit |
Ctrl-c |
Start a new draft |
Composer:
| Key | Action |
|---|---|
Ctrl-e, Alt-e |
Hand off to $VISUAL or $EDITOR for the current draft |
Esc |
Open the compose actions dialog (Send, Preview, Save to Drafts, Cancel) |
The --keybinds <vim|emacs> flag (and the top-level keybinds = "emacs" TOML field) changes the in-app composer's edtui keybinds. In Vim mode, Ctrl-e (edtui's normal-mode binding) opens the external editor; in Emacs mode, Ctrl-e is rebound to "move to end of line" and Alt-e is the only system-editor key.
Envelope dialog actions: Read, Reply, Reply All, Forward, Copy, Move, Add flag, Remove flag.
Drafts are written in MML and compiled to MIME on send. Headers (From, To, Subject…) live at the top of the buffer; the body and any MML directives (attachments, signing, encryption) follow.
Sending routes through SMTP when an [accounts.<name>.smtp] block is configured, otherwise through JMAP. Drafts can be saved to the Drafts mailbox at any time.
Himalaya TUI is one of several front-ends to the Pimalaya libraries. See pimalaya/himalaya#interfaces for the full list (CLI, Vim, Emacs, Raycast).
This project is developed with AI assistance. This section documents how, so users and downstream packagers can make informed decisions.
-
Tools: Claude Code (Anthropic), Opus 4.7, invoked locally with a persistent project-scoped memory and a small set of repo-specific rules.
-
Used for: Refactors, mechanical multi-file edits, boilerplate (feature gates, error enums, derive macros, trait impls), test scaffolding, doc polish, exploratory design conversations.
-
Not used for: Engineering, critical code, git manipulation (commit, merge, rebase…), real-world tests.
-
Verification: Every AI-assisted change is read, compiled, tested, and formatted before commit (
nix develop --command cargo check / cargo test / cargo fmt). Behavioural correctness is verified against the relevant RFC or upstream spec, not assumed from the model output. Tests are never adjusted to fit AI-generated code; the code is adjusted to fit correct behaviour. -
Limitations: AI models occasionally produce code that compiles and passes tests but is subtly wrong: off-by-one errors, missed edge cases, plausible but nonexistent APIs, stale RFC references. The verification workflow catches most of this; it does not catch all of it. Bug reports are welcome and taken seriously.
-
Last reviewed: 31/05/2026
- Chat on Matrix
- News on Mastodon or RSS
- Mail at pimalaya.org@posteo.net
Special thanks to the NLnet foundation and the European Commission that have been financially supporting the project for years:
- 2022 → 2023: NGI Assure
- 2023 → 2024: NGI Zero Entrust
- 2024 → 2026: NGI Zero Core
- 2027 in preparation…
If you appreciate the project, feel free to donate using one of the following providers: