GUILHERME YAMAKAWA DE OLIVEIRA

PT|EN

Link routing: the feature OSes and browsers pretend isn't there

I switched from Mac to Linux with Omarchy almost a year ago. Most things slid back into place. There's one thing still bothering me, and turns out it's not just a Linux problem. There's a simple feature no OS ships and no browser ships: rules for deciding which browser or app opens each link you click.

On Mac I used Finicky for this. For anyone who never saw it: it lets you write rules that decide which browser opens each link. You set Finicky as the system's default browser, and it applies your rules to every link clicked in any app, picking the right one. Rules are short scripts in JavaScript, simple or as elaborate as you need. It can even rewrite the URL before opening it: force HTTPS, strip tracking parameters, or convert it into an internal link that opens the desktop app directly. If no rule matches, it falls through to a backup browser you define.

In practice, it looks like this. A github.com/work-org link opens in the work browser, github.com/personal in the personal one. meet.google.com lands logged into the right profile. YouTube videos always come back to the main browser. Anything that matches no rule falls through to the backup, in my case the personal browser. Work and personal life kept apart without copy-pasting URLs into another window.

There's also the case of apps that ship a desktop client and use their own private address to open it directly. Spotify, WhatsApp, Slack, Discord, Zoom, each has an internal address like spotify:, whatsapp:, slack:, which the system reads as "this link belongs to that app, open it there". When someone shares a public link (open.spotify.com/track/..., wa.me/<phone>, chat.whatsapp.com/<invite>), the right move is to open it straight in the desktop app, not in a browser tab that asks for login and prompts "open in app?" every single time. With Finicky you write a rule that matches the public link and rewrites it to the app's internal address (open.spotify.com/track/abc becomes spotify:track:abc, wa.me/15551234567 becomes whatsapp://send?phone=...), and the system hands it straight to the app. No intermediate tab.

Simple solution, big payoff. That's the strange part.

What exists on Linux

Searched for an equivalent and the most common answer is Junction: pretty, active, well maintained. But it only asks which browser to use on every link. No rules, no auto-routing. There's a community request asking it to remember a default choice and only ask when you hold Alt, but nobody has picked it up. Junction only asks, it doesn't route.

mimi is a more decent replacement for the Linux mechanism that opens links (xdg-open), still without ready-made routing rules.

What's left is the old path: drop a custom shortcut file in the user's apps folder (~/.local/share/applications/), mark that shortcut as the program that opens the system's links, and write a small script that does the routing by hand. It works, but it's a homebrew piece each user has to maintain on their own, with no community in the middle.

The closest thing to Finicky on Linux today is "build your own".

And on Mac?

The Mac landscape is alive. Finicky is actively developed, with v4.2.2 out in October 2025 bringing a visual rules editor. There's Velja, Choosy, Default Tamer, Yojam. A whole third-party market plugging the same gap.

Finicky rules editor Finicky's visual rules editor

Even there it has casualties. Browserosaurus, another community favorite, was archived on August 2, 2025. Maintainer burned out, no official successor. Community has forks, none is canonical.

That's what tends to happen to any third-party tool plugging a gap that neither the OS nor the browser wants to plug.

And on Windows?

On Windows, same story. You set one browser to handle every link in the system, period. No way to say "this site opens here, that other one opens there".

The recent twist is that in 2025 Edge added a toggle for users on a Microsoft corporate account (Entra ID, formerly Azure AD): external links automatically land in Edge's work profile. It's just a global toggle. You pick a profile and that's it. No URL rules, no awareness of which app opened the link.

Outside Edge, the third-party scene on Windows is actually bigger than on Linux. Hurl (active) and mortenn's BrowserPicker (on the Microsoft Store) lead the pack. BrowseRouter is an active fork of the original BrowserSelector, which was archived in 2022. There's also Switchbar, commercial and running on both Mac and Windows.

Same old pattern. Third-party plugs what OS and browser won't, and when the third-party gets archived (hi, BrowserSelector) the community spins up forks, none becoming the canonical one.

Why no OS ships this

The model across operating systems is the same everywhere. macOS, Windows, Linux. For each kind of link, you pick one app that opens it, end of story. A web link (https)? One browser. Email (mailto)? One mail client. Music (spotify)? One app. No way to say "this specific link goes to a different app", or "this link came from Slack so open it somewhere else". Each OS calls this mechanism by a different name (xdg-mime on Linux, LaunchServices on macOS, the registry on Windows), but the limit is the same.

Linux has room to go further since this mechanism is convention, not enforcement, but nobody has moved. macOS and Windows never opened a public API for routing links by rule. Thirty years of desktop OS, and the idea of "this link belongs here, that other link belongs there" still sits outside the system's scope.

Why no browser ships this

Chrome has a selector for picking which profile of Chrome itself opens the link. Firefox has "containers" (a way to isolate tabs into separate compartments), and with extensions (Containerise, Auto Containers) you can route by URL pattern, but all of that only works inside Firefox. No browser wants to hand traffic over to another browser. Each one wants to be the system's default browser.

The incentive math is clear. Sending links to a different browser first reduces the metric that matters for each company, links opened in their own product. The security argument is also there: one trusted default browser is easier to audit than a system that decides where to send things based on URL-matching rules. None of that explains the size of the silence on the OS side.

Meanwhile

This problem has been the same for over ten years. OSes and browsers act like routing a link isn't their responsibility, and every time a third-party tool steps up to fix it, it ends up a solo project until the maintainer burns out. Then everyone goes back to square one (hi, Browserosaurus).

Splitting clicked links by rule is a basic task for anyone juggling more than one context on the same machine. It belongs in the base of the system, at the same level as "which app opens PDFs". Been ten years waiting.

It would be great for this AI era to finally bring a decent cross-platform one for everyone. Mac, Windows and Linux in the same tool. Beyond just using it, I'd be its number-one evangelist. The market is there, we all know that.


Sources:

Comments