Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Captive portal sign-in button uses a hardcoded URL most portals won't recognize
Reported by daffelito · filed Sep 15, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
System details: Omarchy 4.0.0.r2136.g47de632-1
What's wrong?
The Wi-Fi panel's "Sign in to this network" button opens the browser at a URL
hardcoded in Model.js, regardless of how NetworkManager's own connectivity
check is configured:
https://github.com/omacom/omarchy/blob/master/shell/plugins/panels/network/Model.js#L19
var captivePortalUrl = "http://ping.archlinux.org/nm-check.txt"
Most captive portals only intercept the handful of URLs OSes actually use for
connectivity checks (Apple's captive.apple.com, Google's
connectivitycheck.gstatic.com, Microsoft's msftconnecttest.com, GNOME's
nmcheck.gnome.org, etc.) — anything else they just ignore instead of
redirecting. ping.archlinux.org isn't on that list, so on most portals the
button doesn't do anything useful: the browser just loads (or fails to load)
that plain-text file instead of landing on the actual login page.
I hit this after overriding NetworkManager's own [connectivity] uri= to
nmcheck.gnome.org (Arch's default has the same problem for its own
connectivity check, which is a known issue) — that fixed NM's own portal
detection, but the panel's sign-in button still opens archlinux.org since it
doesn't read NM's config at all.
Should either follow whatever NetworkManager's connectivity uri is set to,
or default to one of the widely-recognized check URLs above instead of
Arch's own.
Repro: connect to a captive-portal network that doesn't specifically
allowlist ping.archlinux.org (most of them), click "Sign in to this network"
in the Wi-Fi panel.
Filed by Claude Sonnet 5 via Claude Code.
View raw text
System details: Omarchy 4.0.0.r2136.g47de632-1 What's wrong? The Wi-Fi panel's "Sign in to this network" button opens the browser at a URL hardcoded in Model.js, regardless of how NetworkManager's own connectivity check is configured: https://github.com/omacom/omarchy/blob/master/shell/plugins/panels/network/Model.js#L19 var captivePortalUrl = "http://ping.archlinux.org/nm-check.txt" Most captive portals only intercept the handful of URLs OSes actually use for connectivity checks (Apple's captive.apple.com, Google's connectivitycheck.gstatic.com, Microsoft's msftconnecttest.com, GNOME's nmcheck.gnome.org, etc.) — anything else they just ignore instead of redirecting. ping.archlinux.org isn't on that list, so on most portals the button doesn't do anything useful: the browser just loads (or fails to load) that plain-text file instead of landing on the actual login page. I hit this after overriding NetworkManager's own [connectivity] uri= to nmcheck.gnome.org (Arch's default has the same problem for its own connectivity check, which is a known issue) — that fixed NM's own portal detection, but the panel's sign-in button still opens archlinux.org since it doesn't read NM's config at all. Should either follow whatever NetworkManager's connectivity uri is set to, or default to one of the widely-recognized check URLs above instead of Arch's own. Repro: connect to a captive-portal network that doesn't specifically allowlist ping.archlinux.org (most of them), click "Sign in to this network" in the Wi-Fi panel. Filed by Claude Sonnet 5 via Claude Code.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
- Fixed bypr/13200· confirmed
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 13:44 UTC