Skip to main content
The Email VFS exposes any IMAP mailbox as a virtual filesystem mounted at some prefix such as /email/. Sending is handled via SMTP. Sending through himalaya needs the extra:

Config

Config Reference

Fields marked secret are redacted in snapshots.

Common VFS Settings

For credentials and provider support, see Email setup.

VFS.md

The VFS.md an agent reads with Email mounted at /<path>.

Virtual Filesystem

/<path> layout

Supported Unix Commands for VFS

Unix commands work on each path as on a local filesystem, as far as the path supports them:

Limitations of Unix Commands for VFS

Where a path differs from a local filesystem:Run man <cmd> or <cmd> --help for one command’s usage.
Example:
Folder directories appear at the root, using IMAP folder names (e.g., INBOX, Sent, Drafts).

Date Directories

Inside each folder, messages are grouped into date subdirectories formatted as YYYY-MM-DD. The date is derived from the message’s Date header.

Message Files

Each message is stored as a .email.json file. The filename shape is:

Attachments

Messages that have attachments get a companion subdirectory with the same base name (without .email.json):

Cache

The Email VFS uses IndexCacheStore (same as Gmail, Slack, Discord, and other mounts). Index entries store folder names, message UIDs, and message metadata.

Example

Finding UIDs

VFS-specific commands require message UIDs. These can be extracted from the filesystem:
For composing and sending mail, see the Himalaya CLI.

Shell Commands

Standard commands available on the mounted email tree: Acting on mail (list, read, send, reply, forward) goes through the himalaya CLI when installed.

Integration

What Email answers through its own API, so fewer files are read. Integration explains each command. grep -r and rg read only the messages IMAP SEARCH TEXT names in each folder or day they walk (from the mount root, in every folder), and print what reading every message would. IMAP matches the headers and body in any case; each hit’s file is named from a header-only fetch. Attachments are always read. Every message is read when the text is a key of the message JSON or a flag name, holds anything but ASCII letters and spaces, matches more than max_messages messages in a folder, or the search fails. walk_limit: -1 in the mount’s "@all" command limit reads every file instead, since a server that answers SEARCH from a full-text index (Dovecot with an FTS plugin, for one) matches words rather than substrings, so a narrowed scan could miss a message there.