Tray icon of an already-running app disappears (and never returns) after omarchy-shell restarts

[IgnisNatura]

What happened

An app with a system-tray icon (StatusNotifierItem) was already running when
omarchy-shell restarted (in my case, triggered by an IPC request — I see
omarchy-shell[1135]: INFO: Exiting due to IPC request. in the journal,
likely from a theme/plugin reload). After the new shell process came up, the
app's tray icon never appeared again in the omarchy.tray drawer, even
though the app kept running normally in the background.

I confirmed the mechanism directly over D-Bus: the app still owned its
StatusNotifierItem service name, but the new watcher's registered-item list
was empty:

$ busctl --user get-property org.kde.StatusNotifierWatcher \
    /StatusNotifierWatcher org.kde.StatusNotifierWatcher \
    RegisteredStatusNotifierItems
as 0

Killing and relaunching the affected app made it re-register and its icon
reappeared immediately:

$ busctl --user get-property org.kde.StatusNotifierWatcher \
    /StatusNotifierWatcher org.kde.StatusNotifierWatcher \
    RegisteredStatusNotifierItems
as 1 "org.kde.StatusNotifierItem-<app>-<pid>/StatusNotifierItem"

Why

The StatusNotifierItem protocol only has clients call
RegisterStatusNotifierItem once, at their own startup. It has no mechanism
for a client to notice the watcher itself was replaced and re-register on
its own. So any time omarchy-shell's StatusNotifierWatcher restarts while a
tray app is already running, that app's icon is silently dropped until the
app itself is restarted — the shell has no way to know it's missing an icon
it should have.

Expected

The tray watcher could proactively recover already-running items after its
own restart — e.g. by enumerating current D-Bus names matching
org.kde.StatusNotifierItem-* (or org.freedesktop.StatusNotifierItem-*)
on startup and querying them directly, rather than relying solely on them
calling RegisterStatusNotifierItem again.

Steps to reproduce

1. Launch any app that registers a tray icon (I used ProtonVPN's GTK app,
   proton-vpn-gtk-app).
2. Confirm its icon shows in the omarchy.tray drawer.
3. Restart omarchy-shell (e.g. omarchy-shell shell rescanPlugins, a theme
   switch, or any other action that sends the shell an IPC restart request)
   without closing the app.
4. Hover the tray drawer again — the icon is gone. The app is still running
   and its VPN/whatever functionality is unaffected; only the tray
   registration is lost.

System

• omarchy 4.0.3-1
• quickshell 0.3.1-1
• Hyprland, Arch Linux

Related

Possibly the same underlying StatusNotifierWatcher-lifecycle-across-restart
root cause as #7957 ("Restarting Omarchy Shell reopens tray-resident
Spotify and steals focus"), but the opposite symptom: there, Spotify's item
survives the restart and the shell re-focuses its window; here, the item is
dropped entirely and needs the app itself relaunched to reappear.

[IgnisNatura]

Follow-up with two findings that I think make this cheaper to fix than the original report suggested.

1. There is a first-party one-line reproduction.

omarchy restart shell triggers it directly, no theme switch or IPC poking needed:

$ busctl --user get-property org.kde.StatusNotifierWatcher \
    /StatusNotifierWatcher org.kde.StatusNotifierWatcher \
    RegisteredStatusNotifierItems
as 1 "org.kde.StatusNotifierItem-proton.vpn.app.gtk-45061/StatusNotifierItem"

$ omarchy restart shell

$ busctl --user get-property org.kde.StatusNotifierWatcher \
    /StatusNotifierWatcher org.kde.StatusNotifierWatcher \
    RegisteredStatusNotifierItems
as 0

The app is still running and still owns its well-known SNI bus name throughout. Only the watcher's list is emptied.

2. The dropped item can be recovered without restarting the app, by a third party.

This is the part I did not know when I filed. RegisterStatusNotifierItem accepts the service name as its s argument, and the watcher honors that argument rather than the caller's unique name. So any process on the bus can re-register a live item on the app's behalf:

$ busctl --user call org.kde.StatusNotifierWatcher \
    /StatusNotifierWatcher org.kde.StatusNotifierWatcher \
    RegisterStatusNotifierItem s "org.kde.StatusNotifierItem-proton.vpn.app.gtk-45061"

$ busctl --user get-property org.kde.StatusNotifierWatcher \
    /StatusNotifierWatcher org.kde.StatusNotifierWatcher \
    RegisteredStatusNotifierItems
as 1 "org.kde.StatusNotifierItem-proton.vpn.app.gtk-45061/StatusNotifierItem"

The icon comes back immediately, the app's PID never changes, and re-registering an item that is already registered is a no-op rather than a duplicate.

That supports the recovery approach suggested in the original report, and suggests it is self-contained: on watcher startup, enumerate bus names matching org.kde.StatusNotifierItem-* and org.freedesktop.StatusNotifierItem-* and register them, with no cooperation needed from the client apps and no protocol extension.

Why the "just restart the app" workaround is not good enough

Worth spelling out, because it is what pushed me to look for the above. I had been running a systemd user timer that detected the stale icon and relaunched the affected app. The app in question is a VPN client with a kill switch bound to the tunnel. Restarting it tears down the tunnel and reconnects to a different server, so every firing of that timer turned a cosmetic icon fault into a real connectivity outage with all traffic halted in between. For anything holding a connection, a session, or unsaved state, "restart the app to get your icon back" is a genuinely costly workaround, so recovering the item in the watcher is worth more than it might look.

Versions unchanged from the original report, now on omarchy 4.0.4-1, quickshell 0.3.1-1.