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.
Network widget misreports Wi-Fi when TUN interface is active
Reported by unship · filed Sep 1, 2026Closed upstream on 2026-09-21 by bjarneo via an automated message, as a duplicate of #7438 (R-1669). GitHub close reason: completed.
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?
- Not yet mapped to any requirement or component.
- 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?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
Description
The Omarchy network bar/widget can report the wrong connection state when a TUN interface is active and used for ip route get 1.1.1.1, even though NetworkManager shows Wi-Fi connected.
In this state, the upper bar network button shows no Wi-Fi connected / does not show the connected SSID. The machine is actually connected to Wi-Fi.
Expected behavior
The network widget should show the active Wi-Fi SSID/signal when NetworkManager has a connected Wi-Fi device, or otherwise distinguish the TUN/VPN/proxy route from a wired Ethernet connection.
Actual behavior
NetworkManager reports Wi-Fi connected to SSID 612 on wlp3s0, but Omarchy's status helper reports the TUN interface Meta as ethernet:
$ nmcli -t -f DEVICE,TYPE,STATE,CONNECTION device status
wlp3s0:wifi:connected:612
lo:loopback:connected (externally):lo
Meta:tun:connected (externally):Meta
p2p-dev-wlp3s0:wifi-p2p:disconnected:
tailscale0:tun:unmanaged:
$ nmcli -t -f NAME,TYPE,DEVICE connection show --active
612:802-11-wireless:wlp3s0
lo:loopback:lo
Meta:tun:Meta
$ ip route get 1.1.1.1
1.1.1.1 via 198.18.0.2 dev Meta table 2022 src 198.18.0.1 uid 1000
cache
$ ip route
default via 192.168.0.1 dev wlp3s0 proto dhcp src 192.168.0.109 metric 600
192.168.0.0/24 dev wlp3s0 proto kernel scope link src 192.168.0.109 metric 600
198.18.0.0/30 dev Meta proto kernel scope link src 198.18.0.1
$ omarchy-network-status
ethernet Meta
$ omarchy-network-status --verbose
iface Meta
ip 198.18.0.1
prefix 30
gateway 198.18.0.2
rx_bytes 576437191
tx_bytes 7873409
type ethernet
speed 10000
duplex full
router_ping_ms 0.229
internet_ping_ms 203Steps to reproduce
- Connect to Wi-Fi using NetworkManager.
- Start a VPN/proxy/TUN interface that causes
ip route get 1.1.1.1to resolve through the TUN device. - Check the Omarchy upper bar network button/widget.
- Compare with
nmcli device statusandomarchy-network-status.
System details
- Omarchy version:
4.0.2-1 - Omarchy channel:
stable - Shell process:
quickshell -n -p /usr/share/omarchy/shell
Notes
This appears related to /usr/share/omarchy/bin/omarchy-network-status using ip route get 1.1.1.1 and treating any default-route device without /sys/class/net/$device/wireless as Ethernet. TUN interfaces such as Meta are therefore reported as ethernet, while the underlying Wi-Fi connection remains connected.
View raw text
## Description
The Omarchy network bar/widget can report the wrong connection state when a TUN interface is active and used for `ip route get 1.1.1.1`, even though NetworkManager shows Wi-Fi connected.
In this state, the upper bar network button shows no Wi-Fi connected / does not show the connected SSID. The machine is actually connected to Wi-Fi.
## Expected behavior
The network widget should show the active Wi-Fi SSID/signal when NetworkManager has a connected Wi-Fi device, or otherwise distinguish the TUN/VPN/proxy route from a wired Ethernet connection.
## Actual behavior
NetworkManager reports Wi-Fi connected to SSID `612` on `wlp3s0`, but Omarchy's status helper reports the TUN interface `Meta` as `ethernet`:
```text
$ nmcli -t -f DEVICE,TYPE,STATE,CONNECTION device status
wlp3s0:wifi:connected:612
lo:loopback:connected (externally):lo
Meta:tun:connected (externally):Meta
p2p-dev-wlp3s0:wifi-p2p:disconnected:
tailscale0:tun:unmanaged:
$ nmcli -t -f NAME,TYPE,DEVICE connection show --active
612:802-11-wireless:wlp3s0
lo:loopback:lo
Meta:tun:Meta
$ ip route get 1.1.1.1
1.1.1.1 via 198.18.0.2 dev Meta table 2022 src 198.18.0.1 uid 1000
cache
$ ip route
default via 192.168.0.1 dev wlp3s0 proto dhcp src 192.168.0.109 metric 600
192.168.0.0/24 dev wlp3s0 proto kernel scope link src 192.168.0.109 metric 600
198.18.0.0/30 dev Meta proto kernel scope link src 198.18.0.1
$ omarchy-network-status
ethernet Meta
$ omarchy-network-status --verbose
iface Meta
ip 198.18.0.1
prefix 30
gateway 198.18.0.2
rx_bytes 576437191
tx_bytes 7873409
type ethernet
speed 10000
duplex full
router_ping_ms 0.229
internet_ping_ms 203
```
## Steps to reproduce
1. Connect to Wi-Fi using NetworkManager.
2. Start a VPN/proxy/TUN interface that causes `ip route get 1.1.1.1` to resolve through the TUN device.
3. Check the Omarchy upper bar network button/widget.
4. Compare with `nmcli device status` and `omarchy-network-status`.
## System details
- Omarchy version: `4.0.2-1`
- Omarchy channel: `stable`
- Shell process: `quickshell -n -p /usr/share/omarchy/shell`
## Notes
This appears related to `/usr/share/omarchy/bin/omarchy-network-status` using `ip route get 1.1.1.1` and treating any default-route device without `/sys/class/net/$device/wireless` as Ethernet. TUN interfaces such as `Meta` are therefore reported as `ethernet`, while the underlying Wi-Fi connection remains connected.
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.
No decision has been recorded yet.