Network bar icon shows disconnected while Wi-Fi is up (kind uses scan-derived connectedWifiNetwork, stale while panel closed)

[kosovim-dev]

System details

• Omarchy: 4.0.0.r2037.g97a86af-1
• Quickshell: 0.3.1
• NetworkManager: 1.58.1
• Kernel: 7.2.3-arch1-2
• CPU: Intel Core i7-4770HQ, GPU: Intel Crystal Well integrated

What happened

With the network panel closed, the bar's network widget shows the
"disconnected" glyph (and kind-derived state) while Wi-Fi is associated,
has the default route, and internet works. It stays wrong until the panel is
opened, which restarts scanning and repopulates the network list.

What I expected

The Wi-Fi signal icon whenever the radio is connected, whether or not the
panel has been opened since the shell started.

Root cause

shell/plugins/panels/network/Panel.qml derives the bar icon's kind from
the scan-derived access-point list:

readonly property string kind: {
  if (wiredDevice && wiredDevice.connected) return "ethernet"
  if (connectedWifiNetwork) return "wifi"
  return "disconnected"
}

connectedWifiNetwork comes from wifiDevice.networks, which is populated
by scans. Scanning is deliberately paused while the panel is closed
(setScannerEnabled() only holds scannerEnabled on the device while
opened), so connectedWifiNetwork can be null while the radio is up —
for example after the dock's ethernet is unplugged, or after anything that
rebuilds the NM device list with the panel closed (a VPN integration
adding/removing dummy devices, such as ProtonVPN's pvpn-killswitch /
ipv6leakintrf0). The comment in the existing code already acknowledges the
wired equivalent of this class of problem ("the first-enumerated one may be
carrierless" in findDevice()), and the wired branch of kind correctly
uses live device state (wiredDevice.connected) — but the Wi-Fi branch
depends on scan-derived state that is stale by design while the panel is
closed.

Steps to reproduce

1. Connect to Wi-Fi, keep the network panel closed.
2. While it is closed, trigger a rebuild of the scan-derived network list —
   e.g. unplug the dock ethernet, or connect/disconnect a VPN whose NM
   integration adds and removes dummy devices.
3. The bar icon flips to the disconnected glyph even though ping and
   browsing still work over Wi-Fi. Opening the network panel clears it.

Fix

Use the Wi-Fi device's own connected flag, mirroring the wired branch.
wifiDevice already comes from findDevice(), which prefers a connected
device:

   readonly property string kind: {
     if (wiredDevice && wiredDevice.connected) return "ethernet"
-    if (connectedWifiNetwork) return "wifi"
+    if (wifiDevice && wifiDevice.connected) return "wifi"
     return "disconnected"
   }

I have been running a cloned network panel with exactly this one-line change
since 2026-09-06: the icon tracks Wi-Fi state correctly with the panel
closed, including through VPN connect/disconnect cycles and dock
plug/unplug. Happy to turn this into a PR if that's preferred.

Related staleness with the same root cause: signalStrength also reads
connectedWifiNetwork and reports -1 in this state, which degrades the
signal-glyph choice too — worth addressing if the fix is extended.

[wundrellama]

Related report from a Wi-Fi laptop with a full-tunnel WireGuard connection, controlled by wg-quick through omarchy-vpn.

Observed behavior

The network icon alternates unpredictably between the full Wi-Fi fan and the slashed Wi-Fi fan while the tunnel is active. It does not show the exclamation-mark variant. This is the Wi-Fi icon, not the separate VPN shield.

The panel sometimes reads "Ethernet" beside the slashed Wi-Fi fan. That label also appeared before any local diagnostic edits.

Workaround result

We applied this NetworkManager configuration and reloaded NetworkManager:

[keyfile]
unmanaged-devices=type:wireguard

NetworkManager then reported the tunnel as unmanaged and the Wi-Fi device as connected. Routing and DNS still worked through the tunnel.

The icon continued to alternate after this change and after a shell restart. The unmanaged rule did not resolve this symptom.

Evidence limits

NetworkManager checks during the investigation reported Wi-Fi connected and connectivity full. We did not capture a synchronized trace of an intermittent icon change and its underlying properties.

Temporary QML logs captured connectedWifiNetwork=NULL with a Wi-Fi device present during widget initialization. These startup observations do not establish the cause of the later intermittent changes.

We removed the temporary widget edits and restored the stock network widget. We did not test the device-state fix proposed in this issue. Its effect on this particular case remains unknown.

Related header fix

PR #8866 addresses the separate omarchy-network-status classification problem. A local test of its helper selected the physical Wi-Fi interface instead of the tunnel.

The PR author requested a separate issue for the icon in this reply. This existing issue appears to be the appropriate place.

This also corrects my earlier PR comment: the header test succeeded, but it did not verify an icon fix. The claimed explanation for the intermittent icon changes was not established.

Environment during the original investigation

• Omarchy development checkout. Reported versions included dev (b679363b) and later dev (86a2e583).
• Package: omarchy-dev 4.0.0.r2128.gb679363-1.
• NetworkManager: 1.58.1.
• VPN manager: omarchy-vpn 0.4.5.
• Full-tunnel WireGuard configuration: AllowedIPs = 0.0.0.0/0, ::/0.

These are the versions recorded during the investigation, not a fresh reproduction on the latest release.

[victoralekseev5597]

Still reproduces on Omarchy 4.0.4-1 (quickshell 0.3.1-1, NetworkManager 1.58.1-1). The kind binding in Panel.qml is unchanged. This looks like the same symptom as #11200.

What differs from the original report

• Trigger: boot race, no dock or VPN involved. The shell started at 22:34:43. NetworkManager moved wlp3s0 from disconnected to activated between 22:34:42 and 22:34:44, so the shell came up while the connection was still being made.
• Opening the panel did not fix it. The icon showed the disconnected glyph. Opening the panel showed the SSID (taken from omarchy-network-status) next to "NOT CONNECTED", and it stayed that way after the panel's scan. So in this case Quickshell's WifiNetwork.connected stayed false even after a rescan, not only while the panel was closed.
• omarchy restart shell fixed it right away.

NetworkManager state while the UI showed disconnected

$ nmcli -t general status
connected:full:enabled:enabled:missing:enabled:no (guessed)
$ nmcli -f GENERAL.STATE dev show wlp3s0
GENERAL.STATE:  100 (connected)
$ busctl get-property org.freedesktop.NetworkManager <wlp3s0 path> org.freedesktop.NetworkManager.Device.Wireless ActiveAccessPoint
o "/org/freedesktop/NetworkManager/AccessPoint/2"      # SSID matches, marked IN-USE in `nmcli dev wifi list`

omarchy-network-status --verbose reported type wifi, the correct SSID, -63 dBm, and working router and internet pings.

The fix proposed here (wifiDevice.connected instead of connectedWifiNetwork) would cover this case for the bar icon. The panel's canDisconnect and "NOT CONNECTED" label read the same stale object, so they would need the same change.