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.
Tailscale panel: exit node rows show OS hostname instead of MagicDNS name
Reported by ssandys · filed Sep 6, 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
What happens
The Tailscale panel's EXIT NODES list labels a node with its OS hostname. Every other Tailscale client — the CLI, the tsui TUI, and the admin console — uses the MagicDNS name, so the panel disagrees with all of them.
On my tailnet, one machine has HostName: "Firezone" and DNSName: "ny-exit-node.tailcb223.ts.net":
| Client | Label |
|---|---|
tailscale exit-node list | ny-exit-node |
tsui 0.2.0 | ny-exit-node |
| Tailscale admin console | ny-exit-node |
| Omarchy panel | `Firezone` |
The panel shows atl-exit-node, Firezone, sfo-exit-node where every other tool shows atl-exit-node, ny-exit-node, sfo-exit-node. It reads as though one exit node is missing and an unrelated machine has appeared.
Why it matters
In the MACHINES list a name is a friendly label, and the OS hostname is genuinely the nicer choice. In EXIT NODES it is an identifier you cross-reference against tailscale exit-node list, the admin console, and tailscale set --exit-node=. Those should agree.
Cause
displayHostName (shell/plugins/panels/tailscale/Model.js:32-36) prefers HostName, falling back to MagicDNS only when it is empty or localhost. peerFromStatus uses it for both HostName and DisplayName, and the exit node row renders DisplayName at Panel.qml:1121.
This is cosmetic only — exitNodeTarget → peerAddress (Service.qml:128-133) already prefers DNSName, so selecting the row runs the correct tailscale set --exit-node=ny-exit-node.tailcb223.ts.net.
Suggested fix, and what not to do
Add an exitNodeLabel(peer) helper used only by exit node rows, preferring shortDnsName(peer.DNSName) and keeping DisplayName for Mullvad region rows (which need "Stockholm, Sweden", not a .mullvad.ts.net host).
`displayHostName` should not be changed globally. On my 367-peer tailnet, 169 peers have a HostName differing from their MagicDNS name, but ~132 are pure slugification (Dana's MacBook Pro → danas-macbook-pro), where the OS hostname is the better label. Of the 37 semantically different names, 34 are localhost — already handled by the existing !== "localhost" guard, which is why the list shows iphone172-3 and not 34 rows named "localhost". A global flip would degrade the machine list to fix one exit node row.
Environment
- omarchy-dev 4.0.0.r2031.g41b6cc6-1 (quattro)
- tailscale 1.102.3
- Tailnet with 367 peers, 3 exit nodes
View raw text
### What happens The Tailscale panel's EXIT NODES list labels a node with its OS hostname. Every other Tailscale client — the CLI, the `tsui` TUI, and the admin console — uses the MagicDNS name, so the panel disagrees with all of them. On my tailnet, one machine has `HostName: "Firezone"` and `DNSName: "ny-exit-node.tailcb223.ts.net"`: | Client | Label | |---|---| | `tailscale exit-node list` | `ny-exit-node` | | `tsui` 0.2.0 | `ny-exit-node` | | Tailscale admin console | `ny-exit-node` | | **Omarchy panel** | **`Firezone`** | The panel shows `atl-exit-node`, `Firezone`, `sfo-exit-node` where every other tool shows `atl-exit-node`, `ny-exit-node`, `sfo-exit-node`. It reads as though one exit node is missing and an unrelated machine has appeared. ### Why it matters In the MACHINES list a name is a friendly label, and the OS hostname is genuinely the nicer choice. In EXIT NODES it is an identifier you cross-reference against `tailscale exit-node list`, the admin console, and `tailscale set --exit-node=`. Those should agree. ### Cause `displayHostName` (`shell/plugins/panels/tailscale/Model.js:32-36`) prefers `HostName`, falling back to MagicDNS only when it is empty or `localhost`. `peerFromStatus` uses it for both `HostName` and `DisplayName`, and the exit node row renders `DisplayName` at `Panel.qml:1121`. This is cosmetic only — `exitNodeTarget` → `peerAddress` (`Service.qml:128-133`) already prefers `DNSName`, so selecting the row runs the correct `tailscale set --exit-node=ny-exit-node.tailcb223.ts.net`. ### Suggested fix, and what *not* to do Add an `exitNodeLabel(peer)` helper used only by exit node rows, preferring `shortDnsName(peer.DNSName)` and keeping `DisplayName` for Mullvad region rows (which need "Stockholm, Sweden", not a `.mullvad.ts.net` host). **`displayHostName` should not be changed globally.** On my 367-peer tailnet, 169 peers have a `HostName` differing from their MagicDNS name, but ~132 are pure slugification (`Dana's MacBook Pro` → `danas-macbook-pro`), where the OS hostname is the better label. Of the 37 semantically different names, 34 are `localhost` — already handled by the existing `!== "localhost"` guard, which is why the list shows `iphone172-3` and not 34 rows named "localhost". A global flip would degrade the machine list to fix one exit node row. ### Environment - omarchy-dev 4.0.0.r2031.g41b6cc6-1 (quattro) - tailscale 1.102.3 - Tailnet with 367 peers, 3 exit nodes
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
Not linked to any known issue, other report or change yet.
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 10:58 UTC