Version 1.24.0 is an active desktop client with paid extras
Mailspring is the continuation of Nylas Mail led by one of its original authors. The interface is an Electron and React application written in TypeScript, while mail synchronization runs locally through a separate C++ engine. Day-to-day features include a unified inbox, snoozing, scheduled sending, rules, and templates. The client runs on Windows, macOS, and Linux, with deb, rpm, and snap downloads linked from the README.
Some of the most marketable features are not part of the free experience. A monthly Mailspring Pro subscription unlocks link tracking, read receipts, mailbox analytics, and contact or company profiles. The README says email credentials stay in the client, an important distinction from sending passwords to a hosted sync service. Buyers still need to decide whether the free feature set is enough before investing in themes, plugins, and account migration.
The C++ sync engine lives in a second repository
The Electron application starts a local sync process based on Mailcore2. Its GPL-3.0 source lives in Foundry376/Mailspring-Sync, not inside this checkout. For convenience, the development setup downloads the latest engine binary shipped for the user's platform. That saves contributors from compiling its C and C++ dependencies, but it also means this repository alone is not the complete source-build input for the application they run.
What happened when we ran it
Our sandbox cloned commit f3ce9f0 into a 239.3 MB checkout containing 9,215 files and roughly 552,041 lines of source. npm install failed with exit code 1 after 380 seconds. The final log identifies better-sqlite3 version 12.11.1, node-gyp version 12.2.0, and Node version 18.20.8 before reporting gyp ERR! not ok.
The repository postinstall command then exited with code 1. The log tail does not include the earlier compiler message, so it cannot support a more specific diagnosis. It would be speculation to blame one missing library, compiler version, or Node mismatch from these lines alone. The useful result is narrower: installation did not finish in our fresh 3-CPU, 8 GB, unprivileged container, and no build or test result followed it.
Our scan found 5 CI workflow files, no Dockerfile, and no tests directory. The package manifest does expose build and test scripts, but the failed install prevented the supplied run from reaching them. We therefore have no measured build time, passing test count, dependency total, or audit result for this commit. The repository signals show automation exists; they do not turn an interrupted local install into a passing verification run.
A 380-second failure exposes dated contributor guidance
The root README makes source startup look short: run npm install, then npm start. CONTRIBUTING adds the details. It recommends Node 16.x with npm 8.1.2 or newer, Python 2.7 on Linux, a C++11 compiler, and distribution-specific X11, keyboard, secret-store, and other libraries. Those instructions sit awkwardly beside release 1.24.0, which updated the packaged application to Electron 44 with Node.js 24.20.
That mismatch did not necessarily cause our better-sqlite3 failure. The log does not say. It does mean a new contributor must reconcile the current manifest, native module support, Electron's ABI, and platform packages rather than copying one version line from the guide. A reproducible container or refreshed prerequisite matrix would make this much easier. Until then, use the prebuilt desktop package for evaluating mail behavior and reserve source setup for people ready to debug native builds.
MCP uses port 2587, a bearer token, and three access levels
Mailspring now contains a local Model Context Protocol server for agents. Its code binds to 127.0.0.1, serves /mcp, and defaults to port 2587. Requests need a generated bearer token, and the transport checks loopback Host values to reduce DNS-rebinding risk. Release 1.24.0 added a get_attachment tool so a local agent can retrieve attachment content as an MCP resource.
Permissions deserve a deliberate pass before activation. The access levels are read-only, read-write, and read-write-send, with read-only as the default. Account and folder exclusions are checked by tools, and mutating batch operations fail when any selected thread is blocked. However, the source treats an empty account configuration as permission to read every configured account. Set explicit accounts and excluded folders, keep send disabled unless required, protect the token, and review the built-in MCP audit view.
The September 2026 release and issue activity show maintenance
GitHub showed 17,797 stars, 22 open issues and pull requests, and a last push on September 13, 2026. Version 1.24.0 was published that day. Its notes cover calendar corrections, composer crash fixes, Linux desktop handling, updated translations, MCP attachment access, and an Electron upgrade. An issue opened September 14 reports a double title bar on KDE, showing users are testing the new build rather than only discussing old versions.
The same release raises the minimum Mac version to macOS 13 because Chromium dropped macOS 12. Flatpak users may be asked to authenticate accounts again after the secret-storage path changed. Those upgrade notes are specific and useful. They also show why an email client cannot be judged only by repository stars: every OS integration, credential store, provider, calendar edge case, and Electron update creates behavior that must be checked on the user's actual desktop.
The 239.3 MB source tree suits users before contributors
Mailspring has a clear product identity: a polished multi-account desktop client with a plugin-friendly TypeScript interface. For someone downloading a signed package, its current release cadence and detailed change log justify a trial. Test account authentication, mail search, calendar behavior, local secret storage, and any paid feature before moving a primary inbox. macOS 12 users should stop at the version requirement.
Contributors face a harder choice. Our 380-second install failure came before any build or test could prove the checkout, and the native prerequisites in CONTRIBUTING lag the runtime named in the latest release. Thunderbird is the safer all-free default. Mailspring is worth choosing when its interface, workflow features, or controlled local MCP access is the reason for the switch, and when someone on the team can own native Electron dependency failures.