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-or-focus / omarchy-launch-spotify match window titles, so any window with the app name in its title hijacks the keybinding
Reported by chriguschneider · filed Sep 1, 2026Closed upstream on 2026-09-21 by bjarneo via an automated message, as a duplicate of #7154 (R-1757). 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
What happened
SUPER+SHIFT+M (Music) appeared to do nothing — Spotify never launched. Instead, focus silently jumped to an unrelated window on another workspace.
Root cause: bin/omarchy-launch-spotify looks for an existing Spotify window by matching the pattern against both `.class` and `.title` of every Hyprland client:
WINDOW_ADDRESS=$(hyprctl clients -j | jq -r '.[]|select((.class|test("\\bspotify\\b";"i")) or (.title|test("\\bspotify\\b";"i")))|.address' | head -n1)Any window whose title merely contains the word "spotify" is treated as the Spotify app and gets focused instead of launching Spotify. In my case it was an Omarchy agent window (class: org.omarchy.agent) — a Claude Code session titled "Spotify player stoppt bei Fensterverschiebung". So Omarchy's own agent windows can hijack the binding. A browser window with "Spotify" in the page title does the same.
The generic bin/omarchy-launch-or-focus has the same class-or-title matcher, so every omarchy launch or focus <pattern> consumer is affected the same way (e.g. a webapp binding labelled "Calendar" being swallowed by an agent window whose task title contains "calendar" — I've hit that variant too).
What I expected
SUPER+SHIFT+M launches Spotify (or focuses the actual Spotify app window if it is already running).
Steps to reproduce
- Make sure Spotify is not running.
- Open any window whose title contains the word "Spotify" — e.g. start an Omarchy/Claude agent session about Spotify, or open a browser tab with "Spotify" in the title.
- Press
SUPER+SHIFT+M. - Focus jumps to that window; Spotify never launches.
Suggested fix
For app launchers like omarchy-launch-spotify, match on .class (or .initialClass) only — the real app is reliably identified by class, and titles are user/content-controlled:
WINDOW_ADDRESS=$(hyprctl clients -j | jq -r '.[]|select(.class|test("\\bspotify\\b";"i"))|.address' | head -n1)For the generic omarchy-launch-or-focus, where title matching may be intentional (TUIs/webapps), consider at least excluding org.omarchy.agent windows from the match so Omarchy's own agent sessions can't swallow app bindings.
System
- Omarchy 4.0.1-1, Arch Linux, Hyprland (three 2560x1440 monitors, scale 1)
- Verified against current
master: bothbin/omarchy-launch-spotifyandbin/omarchy-launch-or-focuscontain the class-or-title matcher. - Local workaround (class-only copy of the launcher + rebind) resolves it.
View raw text
## What happened
`SUPER+SHIFT+M` (Music) appeared to do nothing — Spotify never launched. Instead, focus silently jumped to an unrelated window on another workspace.
Root cause: `bin/omarchy-launch-spotify` looks for an existing Spotify window by matching the pattern against **both `.class` and `.title`** of every Hyprland client:
```bash
WINDOW_ADDRESS=$(hyprctl clients -j | jq -r '.[]|select((.class|test("\\bspotify\\b";"i")) or (.title|test("\\bspotify\\b";"i")))|.address' | head -n1)
```
Any window whose *title* merely contains the word "spotify" is treated as the Spotify app and gets focused instead of launching Spotify. In my case it was an Omarchy agent window (`class: org.omarchy.agent`) — a Claude Code session titled "Spotify player stoppt bei Fensterverschiebung". So Omarchy's own agent windows can hijack the binding. A browser window with "Spotify" in the page title does the same.
The generic `bin/omarchy-launch-or-focus` has the same class-or-title matcher, so every `omarchy launch or focus <pattern>` consumer is affected the same way (e.g. a webapp binding labelled "Calendar" being swallowed by an agent window whose task title contains "calendar" — I've hit that variant too).
## What I expected
`SUPER+SHIFT+M` launches Spotify (or focuses the actual Spotify app window if it is already running).
## Steps to reproduce
1. Make sure Spotify is not running.
2. Open any window whose title contains the word "Spotify" — e.g. start an Omarchy/Claude agent session about Spotify, or open a browser tab with "Spotify" in the title.
3. Press `SUPER+SHIFT+M`.
4. Focus jumps to that window; Spotify never launches.
## Suggested fix
For app launchers like `omarchy-launch-spotify`, match on `.class` (or `.initialClass`) only — the real app is reliably identified by class, and titles are user/content-controlled:
```bash
WINDOW_ADDRESS=$(hyprctl clients -j | jq -r '.[]|select(.class|test("\\bspotify\\b";"i"))|.address' | head -n1)
```
For the generic `omarchy-launch-or-focus`, where title matching may be intentional (TUIs/webapps), consider at least excluding `org.omarchy.agent` windows from the match so Omarchy's own agent sessions can't swallow app bindings.
## System
- Omarchy 4.0.1-1, Arch Linux, Hyprland (three 2560x1440 monitors, scale 1)
- Verified against current `master`: both `bin/omarchy-launch-spotify` and `bin/omarchy-launch-or-focus` contain the class-or-title matcher.
- Local workaround (class-only copy of the launcher + rebind) resolves it.
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.