## The problem

Omarchy has no automatic captive-portal detection or login-page popup. On GNOME, Windows, and macOS, connecting to a hotel/airport/train/cafe/corporate-guest network that requires a browser login automatically pops that login page open for you. On Omarchy, nothing happens — you just silently have no internet until you know to manually open a browser and navigate somewhere to trigger the portal's redirect.

This isn't an edge case. It's one of the most common situations a general, non-technical user hits day to day (hotel wifi, train wifi, coffee shop wifi, an office guest network), and right now there's no way through it without already knowing IT-support-level tricks.

## Evidence this is a recurring pain point, not a one-off

- #1841 collected reports from many users over months hitting "no internet on captive portal" (that thread's root cause turned out to be the old systemd-networkd/iwd DNS regression and got closed when Quattro moved to NetworkManager — but the underlying UX gap, no auto-popup, is untouched by that fix and still present on the NetworkManager-based stack).
- #3445 ("Cannot log into to my university's open wifi") got resolved only because another user happened to know the manual workaround: open a browser and go to `neverssl.com` to force the portal to intercept and redirect you. That's not something a general user should have to be told by a stranger in a GitHub issue.

## Why this matters for Omarchy specifically

Omarchy positions itself as a real daily-driver replacement for mainstream desktop OSes, not just a power-user tinkering project. Captive portal auto-detection is table-stakes networking UX on every OS it's competing with. Without it, anyone who isn't comfortable manually diagnosing a "connected but no internet" state gets stuck the first time they use hotel/airport/cafe wifi — which is a bad first impression for exactly the general users Omarchy is trying to win over.

## What's needed

NetworkManager already does connectivity checking (`nmcli networking connectivity` reports `full`/`limited`/`portal`/`none`). What's missing is a small piece that:
1. watches for NM reporting `portal` (or `limited`, since some portals never resolve to `portal` — see below) connectivity state,
2. opens the default browser to a plain-HTTP URL so the portal's redirect actually fires (note: NetworkManager's own default connectivity-check target, and Apple's `captive.apple.com`, are sometimes specifically pre-auth-allowlisted by portal vendors and won't trigger a redirect or reflect real state — a generic, non-heuristic-target URL like `neverssl.com` is more reliable here),
3. optionally disables IPv6 on the connection first, since some portals (e.g. Deutsche Bahn's WIFIonICE) only intercept IPv4 and blackhole IPv6 instead of redirecting it, hanging the browser.

I built exactly this as a personal `nmcli monitor`-driven systemd user service to work around the gap on my own machine, and I'm happy to share it as a reference implementation if it's useful for building this into Omarchy properly (e.g. as part of the network panel/Setup app) rather than something every user has to reinvent.