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.
Restarting Omarchy Shell reopens tray-resident Spotify and steals focus
Reported by legibet · filed Aug 23, 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
AMD Ryzen AI 9 H 365 / Radeon 880M, Omarchy 4.0.0.r1803.gef6d9e6-1 (edge), Hyprland 0.56.2, Quickshell 0.3.1, Spotify 1.2.96.518
What's wrong?
Restarting Omarchy Shell causes a tray-resident Spotify client to recreate its XWayland main window and steal focus.
Steps to reproduce
- Start Spotify.
- Close its main window while leaving Spotify running in the tray.
- Run
omarchy restart shell(plugin changes that restart the shell have the same effect). - Spotify's main window reappears and becomes active without user input.
Expected: restarting the shell should be transparent to tray applications; Spotify should remain hidden and the current window should keep focus.
Evidence
This reproduced repeatedly. One traced occurrence:
03:55:43.513 omarchy-shell exits due to IPC request
03:55:43.635 new omarchy-shell starts
~03:55:43.78 Hyprland events:
urgent>>...
urgent>>...
openwindow>>...,2,Spotify,Spotify Premium
activewindow>>Spotify,Spotify PremiumAt the same time:
omarchy-launch-spotifywas not accessed or executed.- UWSM recorded no new Spotify launch.
- No MPRIS
Raisemethod was called. - The same Spotify process remained running throughout.
- After the shell restart,
org.kde.StatusNotifierWatcher.RegisteredStatusNotifierItemscontained Spotify at:1.101/org/ayatana/NotificationItem/spotify_client.
This points to the StatusNotifier watcher/host lifecycle during shell restart. Omarchy also sets misc.focus_on_activate = true, which allows the remapped Spotify window to take focus.
Possible mitigations include keeping StatusNotifierWatcher alive independently of the restartable shell, or applying focus_on_activate = false to Spotify by default.
omarchy-debug --no-sudo --print was generated locally; the full log is available if needed but is not attached because it contains unrelated system journal entries.
View raw text
## System details
AMD Ryzen AI 9 H 365 / Radeon 880M, Omarchy `4.0.0.r1803.gef6d9e6-1` (edge), Hyprland `0.56.2`, Quickshell `0.3.1`, Spotify `1.2.96.518`
## What's wrong?
Restarting Omarchy Shell causes a tray-resident Spotify client to recreate its XWayland main window and steal focus.
### Steps to reproduce
1. Start Spotify.
2. Close its main window while leaving Spotify running in the tray.
3. Run `omarchy restart shell` (plugin changes that restart the shell have the same effect).
4. Spotify's main window reappears and becomes active without user input.
Expected: restarting the shell should be transparent to tray applications; Spotify should remain hidden and the current window should keep focus.
### Evidence
This reproduced repeatedly. One traced occurrence:
```text
03:55:43.513 omarchy-shell exits due to IPC request
03:55:43.635 new omarchy-shell starts
~03:55:43.78 Hyprland events:
urgent>>...
urgent>>...
openwindow>>...,2,Spotify,Spotify Premium
activewindow>>Spotify,Spotify Premium
```
At the same time:
- `omarchy-launch-spotify` was not accessed or executed.
- UWSM recorded no new Spotify launch.
- No MPRIS `Raise` method was called.
- The same Spotify process remained running throughout.
- After the shell restart, `org.kde.StatusNotifierWatcher.RegisteredStatusNotifierItems` contained Spotify at `:1.101/org/ayatana/NotificationItem/spotify_client`.
This points to the StatusNotifier watcher/host lifecycle during shell restart. Omarchy also sets `misc.focus_on_activate = true`, which allows the remapped Spotify window to take focus.
Possible mitigations include keeping `StatusNotifierWatcher` alive independently of the restartable shell, or applying `focus_on_activate = false` to Spotify by default.
`omarchy-debug --no-sudo --print` was generated locally; the full log is available if needed but is not attached because it contains unrelated system journal entries.
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 08:33 UTC