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.
omarchy-launch-battlenet has no single-instance guard — every relaunch stacks a headless Proton tree
Reported by zor01010 · filed Sep 26, 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
Environment: Omarchy 4.0.4-1, Hyprland, umu-launcher + GE-Proton 11-7, Battle.net installed via omarchy-install-gaming-battlenet.
What happens
Close the Battle.net window (Super+W or its own X button). Battle.net's default close behaviour is minimise to tray, so it keeps running. In #9245's environment Battle.net registers a StatusNotifier item but its context menu — the only place "Exit" lives — does not open on the current bar. On my machine it was worse: with nine copies running, StatusNotifierWatcher listed exactly one item, and it was Steam's (org/ayatana/NotificationItem/steam). Not one Battle.net copy had a tray icon or a window, so from the user's side it simply vanished.
Relaunch it from the menu. bin/omarchy-launch-battlenet (unchanged on quattro: it ends in env "${env_args[@]}" umu-run "$LAUNCHER" with no check) runs umu-run unconditionally, and because umu-run sandboxes each launch, Battle.net's own single-instance lock never sees the earlier copy. A second headless tree appears.
On my machine I found 9 trees / 61 processes accumulated over 3 days (oldest 2d18h), each ~6 processes (umu-run → srt-bwrap → pv-adverb → proton → umu.exe → Battle.net.exe + Agent.exe), all invisible, on a 16 GB box that was swapping heavily.
Why the Spotify/Signal-style window check alone won't fix it
omarchy-launch-spotify and omarchy-launch-signal focus an existing window before launching, which is enough for them because Electron apps single-instance themselves. The tray-hidden Battle.net copy has no window to focus, and umu-run's sandboxing defeats Battle.net's own instance lock, so a window-only check still falls through to a relaunch.
Suggested fix
Keep the window-focus check (class battle.net.exe, per #10567), and add a process-level one in front of it: detect an existing umu-run whose argument is inside $HOME/Games/battlenet; if it has a window, focus it; if it has none, end the stale tree (or at minimum warn) before launching. Battle.net is the one launcher where a duplicate is genuinely invisible, so it is the one that needs the stronger guard.
Optionally, the installer could set Battle.net's close behaviour to "exit" rather than "minimise to tray", which removes the trigger entirely.
Happy to open a PR if a process-based guard is an acceptable direction.
View raw text
**Environment:** Omarchy 4.0.4-1, Hyprland, umu-launcher + GE-Proton 11-7, Battle.net installed via `omarchy-install-gaming-battlenet`.
**What happens**
Close the Battle.net window (Super+W or its own X button). Battle.net's default close behaviour is *minimise to tray*, so it keeps running. In #9245's environment Battle.net registers a StatusNotifier item but its context menu — the only place "Exit" lives — does not open on the current bar. On my machine it was worse: with nine copies running, `StatusNotifierWatcher` listed exactly one item, and it was Steam's (`org/ayatana/NotificationItem/steam`). Not one Battle.net copy had a tray icon or a window, so from the user's side it simply vanished.
Relaunch it from the menu. `bin/omarchy-launch-battlenet` (unchanged on `quattro`: it ends in `env "${env_args[@]}" umu-run "$LAUNCHER"` with no check) runs umu-run unconditionally, and because umu-run sandboxes each launch, Battle.net's own single-instance lock never sees the earlier copy. A second headless tree appears.
On my machine I found **9 trees / 61 processes** accumulated over 3 days (oldest 2d18h), each ~6 processes (`umu-run → srt-bwrap → pv-adverb → proton → umu.exe → Battle.net.exe + Agent.exe`), all invisible, on a 16 GB box that was swapping heavily.
**Why the Spotify/Signal-style window check alone won't fix it**
`omarchy-launch-spotify` and `omarchy-launch-signal` focus an existing window before launching, which is enough for them because Electron apps single-instance themselves. The tray-hidden Battle.net copy has no window to focus, and umu-run's sandboxing defeats Battle.net's own instance lock, so a window-only check still falls through to a relaunch.
**Suggested fix**
Keep the window-focus check (class `battle.net.exe`, per #10567), and add a process-level one in front of it: detect an existing `umu-run` whose argument is inside `$HOME/Games/battlenet`; if it has a window, focus it; if it has none, end the stale tree (or at minimum warn) before launching. Battle.net is the one launcher where a duplicate is genuinely invisible, so it is the one that needs the stronger guard.
Optionally, the installer could set Battle.net's close behaviour to "exit" rather than "minimise to tray", which removes the trigger entirely.
Happy to open a PR if a process-based guard is an acceptable direction.
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 18:45 UTC