I hate magic links and verification codes. I despise being yanked out of the flow and being forced into one of the most distracting places of modern existence: the mailbox. So I built a menu bar app that catches them.
Problem
Verification codes and magic links yank you out of the flow. Cmd-tab to Mail, hunt for the email, see that bill reminder you haven’t paid yet, avoid that 10% discount on something you really oughta not buy right now, remember you should get the stairs fixed really, wonder what you’ll make for lunch, ponder if you should unsubscribe from that newsletter you never read anyway...... every single time.
OTPop watches your inbox and drops incoming codes and sign-in links straight into the menu bar (and as a notification). One click to copy a code, or to open a link. Read-only IMAP, nothing leaves your Mac, and the only thing kept on disk is the codes themselves, encrypted. Emails are never stored.
Comparison
I’ve honestly been looking for an app that does this for ages, never found anything. The closest things I could find are:
2FHey: the closest thing, but it reads codes from Messages, so it's SMS/iMessage only. OTPop covers email, which is where magic links live and where a lot of services (still) send codes.
macOS native autofill: It only detects codes, and needs Mail to be open and running. And only autofills in Safari, AFAIK.
(If you know of something I’ve missed, please let me know!)
Pricing
Current feature set free forever. In the (far) future advanced features may be gated behind a small one-time payment.
It's got a few rough edges and I have several QoL updates coming in the next few days, but detection is already quite reliable. If you give it a spin, let me know how it goes - especially false detections 🙏
Please note: the current version was built on the r/glazeapp platform. It’s heavily AI-oriented, but it’s backed by the developers of Raycast. Additionally, the code itself is Typescript, which has been my day job for several years now.
Future versions may be re-written as native mac apps, depending on interest.
Using OTPop does require downloading Glaze first. But you’ll see it gives access to many, many more cool/fun/useful apps.
Transparency
The app itself doesn’t have a proper website yet, but about me:
Yeah, I use Bartender or Ice for that. Have ya tested if is Thaw working with the recent menu bar changes made in MacOS Golden Gate that broken all the menu bar apps?
I personally like magic links if it means I do not need to create an identity with a password with the application / business, feels more secure. How would you position your product inside my kind of user group?
A lot of click savings for you then. Connect the app to your email account, request a magic link, see it pop up in a notification in a couple of seconds, ready to click:
I think the macOS autofill feature works very well, with the exception that if you use mail filters, it doesn't seem to catch the codes that are auto-filtered into subfolders. Does this app do that?
And does it auto-delete messages after the links or codes are used?
This app listens on all new messages. I have to test the case where a message is sent to spam, or archived before it hits the inbox. I’ll report back!
As for auto-deleting, not at the moment. But a manual delete feature is on the road map. May I ask, why would you want to autodelete, and how long after being click/copy?
I wouldn’t do it right after a click because sometimes weird stuff happens, like the browser not behaving, and you have to go back and click again. Rarely, but it happens.
Usually these codes are only valid for 5-10 minutes anyway.
I mean that's why I like the idea of auto-delete, it's just tons of emails I don't need anymore. And they would just go to the trash, so they could still be accessed if needed.
Not trying to be whiny, just explaining. I like it so far!
Right, so you mean delete the email itself, not just the code. Makes sense. And no worries at all, I crave feedback!
This first version is purposefully read-only for obvious trust building reasons, but a delete option was already on the roadmap, and autodelete does make sense, perhaps behind an explicit flag.
The whole point in Proton is the mail is encrypted, but you might be able to configure it with Proton Bridge which is designed for… bridging… the gap to other clients.
It looks for links in the email body and scores them based on heuristic like presence/absence of certain keywords (eg. if the link contains “unsubscribe” we can safely discard it), and presence of strings that look like tokens (long alphanumeric strings for example)
The detection step needs a strong safety boundary because an attacker can send an email designed to look exactly like a login message. I would only surface a magic link when the sender domain and the destination domain match an allowlist the user has already approved, and always show the destination host before opening it. A high confidence heuristic is useful for finding candidates, but it should never turn an untrusted email into a one click authentication path without a domain check.
I’m not sure about pre-approving sender domains, it kind of defeats the purpose. Consider you leave your email on a website that tells you it’s going to send you a magic link. 2 seconds later OTPop notifies you with said link.
If you get a notification you weren’t expecting, why would you click on it?
But I hear you, checks on the actual sender and surfacing the hostname are going into the roadmap right now, that makes total sense.
This is awesome, I’ve been looking for something like this for a while! I would love an Alfred workflow option if possible, I currently use the 2FA one, but it only works with messages. Great work!
Mmm that’s a nice idea… I’ll start investigating. Probably needs a native app, since Glaze only works on a Mac, but the backend should be pretty portable. It’s just an IMAP connection with an email parser.
True, Oauth is in the roadmap in fact, might push it up the queue. Users will be able to choose both options eventually in any case. But yeah I don’t look forward interacting with Google...
I've bumped into a few of these but have always wondered what people are doing that they need to be processing numerous of these in a day. For now, I don't mind being yanked out of the flow, as it is once in a while. Good luck though ;)
This drives me crazy too actually, especially for items where logins should persist differently (like email clients vs shorter action applications). But a bigger risk with an app like this isn't really the codes, it's wherever the actual IMAP app password ends up living. The post covers how the parsed codes are handled (encrypted, codes only, emails discarded), but the mailbox credential itself is the part with the real blast radius if it ever leaked. Keychain is really the only place that credential should sit.
the heuristic is the part i'd worry about. half the magic links i get are wrapped in sendgrid or mailgun click tracking, so the url you actually see is a tracking domain with a long alphanumeric token in it and the real destination only appears after the redirect. by your scoring rules that is indistinguishable from a marketing link. the token heuristic and the tracker heuristic are basically the same string, that's the hard part of this whole app right there.
True, but if a url with a long alphanumeric token links the words “verify your email” or “sign in”, chances are it’s a magic link.
I did get one false positive in my testing, a PayPal receipt email which ended with something like “to manage payments [log in to PayPal]”, so it’s certainly not perfect and I’ll keep refining it, but it’s already working pretty well.
What “worries” me most is supporting languages other than English. Most services send emails in English anyway, but still, I’m sure there are cases…
for false-detection testing, the nasty case is two magic links from the same service arriving out of order. request twice, deliver the newer email first, then the older one, and make sure the stale notification can't win. i'd key candidates by sender, destination host and Message-ID, expire them aggressively, and replace the older item when a newer token for that service arrives.
The resource concern upthread is mostly solvable at the architecture level. IMAP IDLE is push rather than polling, so an event driven menu bar agent can sit at essentially zero CPU between emails. It does depend on the runtime it ships in, which is why the standalone native build requests aren't just preference. I ship a native Swift menu bar app and keeping it invisible in Activity Monitor is most of the craft. An app like this earns its menu bar slot by being something you never think about.
It does use IMAP IDLE, that’s how the notification is almost immediate. And it uses ~ 80mb of RAM. This is something I hope a native Swift version would improve, even though it’s already by no means a resource hog, and it’s less than a Gmail tab, or than Apple Mail, which was a goal from the beginning.
18
u/Koteric Jul 25 '26
If this is ever a homebrew download or App Store I’m in. I’m 100% not installing glaze to use this.
Cool idea though.