Prospect Mail: an Outlook web app wrapped as a desktop client

What the application is, and the scope limit that comes with it

Prospect is an Outlook mail desktop client powered by Electron, and the README is direct about the mechanism. It uses the Outlook web app and wraps it as a standalone application using Electron.

That sentence is the whole design, and it determines both the strengths and the limits. You are not getting a native mail client with a real IMAP or Exchange protocol stack. You are getting the Microsoft web application running in a desktop container, with the window management, tray integration and notification handling that the browser tab cannot give you.

The scope limit is stated just as plainly. This only works for Microsoft and Office 365 accounts, and you should not use it for personal Outlook.com accounts. A separate section later in the README repeats the point with a warning that Prospect Mail is only tested in work or educational accounts and that no issues will be reviewed on use for personal accounts, while still providing an example configuration for personal Outlook. So the software can be pointed at a personal account, but the project will not support you if it misbehaves there.

There is a disclaimer that is worth reading in full because it is unusual to see it this prominent. The project has no direct affiliation with Microsoft, Microsoft 365 or any product made by Microsoft.

The application is available for Linux, Windows 10 and later, and macOS, and it is MIT licensed, written in JavaScript with a main entry point at src/main.js. The last push was on 2026-10-12, the recent releases are v1.3.1 on 2026-09-03 with two beta builds of the same version on 2026-09-01, and there is no homepage set beyond the repository itself.

One more piece of context from the topic list: hacktoberfest, which tells you the project takes outside contributions.

The features, and the session recovery that is the real engineering

The feature list is where you can see what the desktop wrapper adds over the web app.

You can check your Outlook Microsoft 365 emails and calendar from the desktop app. The window can close to minimize, and the app can start minimized, toggled through the tray icon settings menu or with the command line flag prospect-mail --minimized. There is dock tray support and system notifications. You can connect to a standard or custom Outlook URL. Spellcheck uses the native Outlook MS Editor. And you can visualise PDF files directly in emails rather than downloading them.

The last two are the ones that make this more than a wrapper. Routing PDFs to the built-in viewer means an attachment opens in the app instead of triggering a download, and using the native editor for spellcheck means the spellchecker is the one your operating system already knows your words in, rather than a browser's approximation.

The automatic session recovery is the most interesting entry, and it is described in enough detail to be useful. Expired auth cookies are cleaned at startup and on wake from sleep. If the Outlook session expires, the app auto-reloads to silently re-authenticate via SSO, and falls back to a desktop notification if a re-login is still needed.

That last design point is the one to appreciate. The application is a browser view of a service that enforces session timeouts, and a plain wrapper would dump the user at a login screen whenever the cookie died, including after the laptop had been asleep. Handling the wake-from-sleep case specifically matters because that is when an app left open in the background reliably finds a dead session.

The tray icon also carries the settings menu, which is where the next part of the configuration lives.

The settings file, and the eleven keys that control the app

Settings are edited as a JSON file, settings.json, opened from the tray menu, and the documentation is unusually complete about what each key does.

The default configuration is:

{
  "urlMainWindow": "https://outlook.cloud.microsoft/mail",
  "urlsInternal": [
    "outlook.cloud.microsoft/mail/deeplink",
    "outlook.cloud.microsoft/calendar/deeplink",
    "outlook.live.com/mail/deeplink",
    "outlook.office365.com/mail/deeplink",
    "outlook.office.com/mail/deeplink",
    "outlook.office.com/calendar/deeplink",
    "to-do.office.com/tasks"
  ],
  "urlsExternal": [
    "outlook.cloud.microsoft",
    "outlook.live.com",
    "outlook.office365.com",
    "outlook.office.com"
  ],
  "safelinksUrls": [
    "outlook.cloud.microsoft/mail/safelink.html",
    "outlook.office.com/mail/safelink.html",
    "safelinks.protection.outlook.com"
  ],
  "showWindowFrame": true,
  "hideOnClose": true,
  "hideOnMinimize": false,
  "startupWindowState": "normal",
  "showUnreadNotifications": true,
  "unreadNotificationSource": "inbox",
  "customBrowserPath": "microsoft-edge"
}

The three URL arrays are the heart of it, and they partition the web into three behaviours. urlsInternal holds URL patterns for deeplinks that open in new app windows, so clicking a calendar invite opens another window of the application rather than navigating the current one. urlsExternal holds the Outlook and Microsoft 365 services that open in the main window. safelinksUrls holds the Microsoft Safe Links patterns that open in an external browser, which matters because Safe Links wrap every link in a redirect page and you do not want that page inside your mail window.

The window keys are more than toggles. showWindowFrame shows or hides the frame and title bar. hideOnClose minimizes to the tray instead of quitting, and hideOnMinimize hides to the tray when minimizing, though the description notes that with it off, minimize stays in the taskbar and restore happens through the tray menu if that is enabled. startupWindowState takes normal, minimized or maximized.

The two notification keys are the ones with the most nuance. showUnreadNotifications controls the new messages desktop notification, with calendar reminders unaffected. And unreadNotificationSource decides which folders drive both the unread badge and the notification, either the Inbox alone or the sum of unread across your Outlook Favorites. That distinction is the difference between a badge that tells you about one folder and one that tells you about the mail you actually care about.

Finally customBrowserPath sets the browser used for external links, accepting a command name such as firefox or a full path, defaulting to the system default.

Settings migration, the new default host, and how a change takes effect

Two notes in the settings section save a lot of confusion, and both are about the version 1.3.0 transition.

The first is about migration. Settings from before 1.3.0 are migrated automatically on the first launch: startMinimized and startMaximized become startupWindowState, and disableUnreadNotifications becomes showUnreadNotifications, inverted. No manual action is needed.

That is a well-behaved schema change, and it is worth noting as a pattern rather than an incident. The old keys encoded the window state as two booleans that were mutually exclusive, and the new key encodes it as an enumeration, and the migration maps one onto the other. The unread notification key is the same shape of change, a boolean inverted into a boolean, which is only possible because the semantics flipped.

The second note is about the default URL. outlook.cloud.microsoft is Microsoft's unified-domain Outlook host and is now the default, while the legacy office.com, office365.com and live.com hosts still work. Existing installs keep their saved urlMainWindow, so the default only applies to new configurations or after you use Restore Default Settings in the tray menu.

The third practical point is that saving the settings file is not enough. After every save you need to click Reload settings to apply the changes, which is a deliberate choice rather than a file watcher, and it means there is one explicit place where a configuration change takes effect.

The example configuration for personal Outlook is provided separately, and it points urlMainWindow at the login.live.com address. The documentation is careful to note that the project is only tested in work or educational accounts and that no issues will be reviewed for personal use, so the example is offered as a starting point for your own experimentation rather than as a supported configuration.

The screenshots in the repository show the mail view and a calendar view, and the top level listing has a build/ directory with the icon, an assets/ directory, a misc/ directory holding the screenshots, a public/ directory for the renderer, a src/ directory, a test/ directory and a .changelogrc.js for the changelog tooling.

How the application is packaged, and what the build scripts reveal

The packaging story is the part that shows how much work an Electron application actually is, and the package.json scripts are a good inventory of it.

There are three plain scripts. Start runs electron ., start-minimized runs electron . --minimized, and test runs node --test, which is the built-in Node test runner with no separate test framework dependency. Pack runs electron-builder --dir for an unpacked directory, and dist runs electron-builder for the full package.

After that come the per-platform targets, and the list is long enough to be interesting. The Linux targets cover AppImage, deb, pacman, rpm, flatpak and tar.gz, each with an x64 and an arm64 variant, and there is a separate set of snap targets for x64 and arm64, plus a combined AppImage target that builds both architectures. The Windows and macOS equivalents sit further down the same list.

So the application ships as seven Linux package formats, two Windows formats and a dmg, and the build matrix is driven by a single electron-builder invocation per format with the architecture passed in. That is a lot of automation, and it is also what makes the download instructions in the README simple, because every Linux distribution is covered by a native package rather than requiring users to install something.

The engines field pins Node at ^24.0.0, which is a current major and tells you what you need to build from source, and the license is MIT with the author recorded as Julian Alarcon.

The Electron version itself is not visible in the readable part of the package file, and since the whole application is a browser engine hosting somebody else's web app, the Chromium version that Electron carries is the thing that determines how the wrapped Outlook application behaves. That is a dependency you inherit rather than choose, and it is worth knowing if the Outlook web app starts behaving differently after an Electron update, because the fix will be in the wrapper's dependency rather than in your account.

Editorial conclusion

Adopt Prospect Mail if you read Microsoft 365 mail in a work account and want a proper window, a tray icon, unread notifications and a way to open links in your own browser. Do not adopt it for a personal Outlook.com account, because the documentation says it is only tested in work or educational accounts and that no issues will be reviewed for personal use. Before you rely on the unread badge, read the settings notes on the migration from the pre-1.3.0 keys and on the new outlook.cloud.microsoft default, and note that a settings change needs the Reload settings action to take effect.

Frequently asked questions

Official sources

1. Issues
2. julian-alarcon/prospect-mail on GitHub
3. License: MIT
4. README
5. Releases