Authy desktop is gone: reading your codes on a Mac instead

Reaching for Authy on a Mac and finding nothing there is a small daily tax that adds up. Every sign-in that used to be a copy and paste is now a phone unlock, a squint, and six digits typed under a thirty second clock. The download page has been rewritten around that reality, and searching for a replacement produces a long list of suggestions with no way to tell which of them actually solve the specific problem of reading a code on a computer. This covers what Authy offers today, which alternatives put codes in reach of a Mac, and how to give the chosen one a window instead of a tab.

What Authy offers today

Authy's download page is the clearest statement available. It carries a single heading, Mobile, and nothing else. There is no desktop section, no macOS entry, and no installer link anywhere on the page.

The features page matches. Its four pillars are setup, security, backup and multiple devices, and the multiple devices section is titled around syncing two-factor authentication across mobile and tablet, with the accompanying line stating that tokens are accessed on iOS and Android platforms. Apple Watch gets a mention. A computer does not. The protections described are Touch ID, a PIN and a password, and encrypted backups stored in Authy's cloud where the decryption password is never received by Authy and therefore cannot be recovered by them.

The support article no longer says anything

Anyone chasing the original end of life announcement will find a dead end. The Twilio help centre article that search engines still index for the Authy desktop retirement now returns a page stating there is currently no content for this article. That is a fact worth knowing because it changes how to approach this: the authoritative statement about the desktop app has been removed, so the download page and the features page are the current record, and both describe a mobile product.

The mobile app itself is alive. Twilio Authy is listed on the App Store under Authy Inc. and requires iOS 15.0 or later. Nothing here is an argument that the app has stopped working, only that a Mac has no version of it to run.

Two questions to answer before moving anything

The temptation is to pick a replacement and start. Two questions decide whether that goes smoothly or badly, and both should be answered before any account is touched.

The first is where the codes actually are right now. A code list built up over years contains entries nobody remembers adding, and some of them protect things that matter more than others. Open the app and read the list from top to bottom, then sort it into two groups: accounts that would be genuinely painful to lose access to, and everything else. The first group gets careful treatment. The second group can be rebuilt casually as each site comes up.

The second is whether the list can be moved rather than rebuilt. This is where expectations need adjusting. Authy's own material describes encrypted backups that sync across mobile and tablet. It does not describe exporting tokens into another application. The safe assumption is that each account will need to be re-enrolled in the new app, one at a time, from that site's own security settings.

Why re-enrolling is less painful than it sounds

Re-enrolment sounds like a weekend. In practice it is a background task spread over a few weeks, because there is no need to do it all at once. Keep Authy installed and working on the phone. Each time a site asks for a code, sign in with Authy as usual, then go into that site's security settings and add the new app as well. Both apps generate valid codes from the same secret if the secret is re-scanned, and many sites allow more than one authenticator.

The accounts in the painful group get done deliberately, with recovery codes printed or saved first. The rest get done opportunistically. The list empties itself.

Where codes can live so a Mac can read them

Four options put a current code in front of a Mac without a phone. The differences that matter are cost, whether the browser surface is included or paid, and whether the tool is a password manager that also holds codes or a dedicated authenticator.

Option	Reads codes in a browser	Cost position	Note
1Password	Yes, on the account web page	Paid only, no free tier	Codes can be added from the web page by pasting the secret
Bitwarden	Yes, in the web vault	Free plan exists, authenticator is Premium	Premium listed at $1.65 per month, billed annually at $19.80
Proton Pass	Yes, web app	Free plan exists, authenticator is Pass Plus	Built-in 2FA authenticator is listed under Pass Plus, not Free
Ente Auth	Yes, web app	Free and open source	AGPL-3.0, with apps for macOS, Windows, Linux, iOS and Android

1Password documents one-time passwords as savable in the browser extension, in the apps, or on the account web page, with one asymmetry: on the web page the secret has to be pasted in by hand, because scanning a QR code from the screen requires the extension or an app. Its personal plans are listed at $2.99 per month paid annually for Individual against a standard $3.99, and $4.49 against $5.99 for Families covering up to five people, with a 14 day trial and no permanently free tier. Accounts are hosted in three regions billing in USD, CAD and EUR, and each region has its own web address, which matters when building a window later.

Bitwarden's pricing page lists an integrated authenticator among its Premium features, with Premium at $1.65 per month billed annually at $19.80 and Families at $3.99 per month for up to six users billed annually at $47.88. The free tier is unusually generous on everything else, covering unlimited devices, unlimited passwords, and browser, mobile and desktop apps, but codes sit on the paid side.

Proton Pass places its built-in 2FA authenticator on Pass Plus rather than on Proton Free, and its free tier covers unlimited logins, unlimited devices, and browser, mobile and desktop apps.

Ente Auth is the closest thing to a like for like replacement in shape, because it is an authenticator rather than a password manager. Its site describes end to end encrypted cloud backups, an offline mode that works without an account, and a platform list covering the App Store, Play Store, F-Droid, web, macOS, Linux and Windows. Import is documented three ways: scanning a QR code, entering the secret manually, and bulk import from other two-factor apps. It is AGPL-3.0 licensed.

Putting the chosen web app in its own window

Three of the four options above ship a desktop application, so for those the honest answer is to install it and skip the rest of this section. The reason to keep reading is the specific case where a browser surface is the one being used: a managed Mac that blocks installs, a machine too old for a current app build, or a second account that the installed app cannot hold at the same time as the first.

Apple documents the Safari route directly. From macOS Sonoma 14 onward, File and then Add to Dock, or the Share button and then Add to Dock, saves the page as a web app. It goes into the Applications folder inside the home folder rather than the system one, so no administrator password is involved, and it opens from the Dock or Spotlight. Apple states that it functions independently of Safari and shares no browsing history, cookies, website data or settings with it. That isolation is the reason this route suits a vault: nothing the rest of a browsing session picks up reaches inside.

Chrome's route is described in its help pages as More, then Cast, save, and share, then Install page as app, with an Install button appearing in the address bar on some sites. The installed app belongs to the Chrome profile that created it, so the existing signed in session carries over. That is convenient and it is also the limitation, because two accounts need two Chrome profiles.

The third route is a purpose built tool, which matters once there is more than one of these to keep tidy. Supported services lists the kinds of sites people most often give their own window, and a credential vault is a recurring entry on that list for obvious reasons.

Getting the address right

For 1Password specifically, the region detail is not optional. Accounts are hosted on three different addresses corresponding to USD, CAD and EUR billing, and a window built on the wrong one lands on a sign-in page that will never accept the account. Open the existing tab, read the address bar, use exactly that host.

Apple's settings panel makes a wrong choice recoverable. Opening the web app, clicking its name in the menu bar and choosing Settings exposes an Application Name field, an Application URL field with a Set to Current Page button, and an Icon picker. The same panel has a Privacy tab that clears the site's stored data including cookies and caches, which is the correct way to sign a window out completely rather than just closing it.

What to check in a window that holds codes

Three things deserve attention, and one of them is a genuine security decision rather than a convenience.

Extensions do not come along automatically. A Safari web app shows a streamlined toolbar with back, forward and Share buttons plus buttons for installed Safari extensions, and its settings include an Extensions tab where those are enabled or disabled for that window specifically. For a vault this cuts both ways. Enabling a password manager extension inside the window means the account password can be filled rather than typed. Enabling nothing means it is typed every time, which some people prefer for the one credential that protects everything else.

Notifications are the second, and the rule is exact: Apple documents that the site's notification request must be answered inside the web app rather than in Safari for the unread count to appear as a badge on the Dock icon. For an authenticator this is rarely needed, but it is the same rule that catches people out elsewhere.

The third is where the codes end up after they leave the window. A code copied to the clipboard is available to anything that reads the clipboard, which is true in a browser tab as well and is not made worse by a window. What a window does change is how visible the vault is: a dedicated icon in the Dock is a clear target, so the name and icon are worth choosing so that it is obvious what the window is and obvious when it is open. The Guide covers how window behaviour gets configured.

Migrating without locking yourself out

Order matters more than speed here. Recovery codes first, for every account in the group that would hurt to lose. Most services offer a set of single use backup codes at the moment two-factor authentication is configured, and saving them somewhere reachable without the new app is the whole safety net.

Keep the phone app until each account is confirmed working elsewhere. Adding a new authenticator does not remove the old one on most services, so there is a window where both produce valid codes and a mistake costs nothing. Only after signing in successfully with the new app should the old entry be removed from that site.

Do the low stakes accounts first to learn the process, then the important ones. And write down which accounts have been moved, because the one guaranteed way to create a bad afternoon is to lose track halfway through and have to guess.

What to change first

Read the whole code list in Authy and mark the handful of accounts that would genuinely hurt to lose, then pick one replacement based on whether a browser surface is needed and whether a free tier matters. Move two unimportant accounts this week to learn the pattern before touching anything that counts. If the replacement ends up being used through a browser, a tool such as Kagemusha gives it a window with its own name and icon rather than a tab that keeps getting lost.