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.
Notification replacement hints honoured by mako are ignored by the 4.0 shell, so progress-style senders stack one toast per update
Reported by lucletoffe · 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 Max+ 395 (Radeon 8060S), Omarchy 4.0.0-1, quickshell-git 0.3.0.r20.g28771c7-2, libnotify 0.8.8-1
What's wrong?
Upgrading from Omarchy 3 to 4 replaces mako with the quickshell notification service. mako replaced any notification carrying the same x-canonical-private-synchronous hint (and x-dunst-stack-tag); the new service inspects only transient (shell/plugins/notifications/Service.qml:151). Every notification posted with that hint is therefore a new toast.
For a one-shot notification nobody notices. For a progress-style sender — a chrono, a volume/brightness OSD, a copy or backup indicator, which post once a second with expire_timeout 0 and rely on the hint to overwrite — the upgrade turns one card that updates into one card per second, none of which ever expires.
Steps:
for i in 1 2 3; do
notify-send -h "string:x-canonical-private-synchronous:demo" "Progress" "$i"
sleep 1
doneOmarchy 3 (mako): one toast, body 3. Omarchy 4: three stacked toasts. Same with x-dunst-stack-tag.
What I am not asking for
Not necessarily that you implement the hints. They are extensions, not part of the spec, and replaces_id is the portable way — that is what I switched my own scripts to.
What is worth deciding is that the change is silent. A script written against the daemon Omarchy itself shipped through 3.x keeps running after omarchy update and quietly floods the desktop, with nothing in the release notes and no error anywhere. Either honouring the two hints (mako's x-canonical-private-synchronous, dunst's x-dunst-stack-tag) as replacement keys, or an explicit line in the 4.0 notes saying they are gone and replaces_id is the way, would close it.
Related, and filed separately as a PR because it is a plain spec-compliance bug rather than a compatibility call: CloseNotification does not remove the toast either — https://github.com/basecamp/omarchy/pull/7833. The two compound. A sender that used the hint to update and CloseNotification to clean up gets neither, which is how the stack ends up permanent.
View raw text
### System details AMD Ryzen AI Max+ 395 (Radeon 8060S), Omarchy 4.0.0-1, quickshell-git 0.3.0.r20.g28771c7-2, libnotify 0.8.8-1 ### What's wrong? Upgrading from Omarchy 3 to 4 replaces mako with the quickshell notification service. mako replaced any notification carrying the same `x-canonical-private-synchronous` hint (and `x-dunst-stack-tag`); the new service inspects only `transient` (`shell/plugins/notifications/Service.qml:151`). Every notification posted with that hint is therefore a *new* toast. For a one-shot notification nobody notices. For a progress-style sender — a chrono, a volume/brightness OSD, a copy or backup indicator, which post once a second with `expire_timeout` 0 and rely on the hint to overwrite — the upgrade turns one card that updates into one card per second, none of which ever expires. Steps: ```bash for i in 1 2 3; do notify-send -h "string:x-canonical-private-synchronous:demo" "Progress" "$i" sleep 1 done ``` Omarchy 3 (mako): one toast, body `3`. Omarchy 4: three stacked toasts. Same with `x-dunst-stack-tag`. ### What I am not asking for Not necessarily that you implement the hints. They are extensions, not part of the spec, and `replaces_id` is the portable way — that is what I switched my own scripts to. What is worth deciding is that the change is silent. A script written against the daemon Omarchy itself shipped through 3.x keeps running after `omarchy update` and quietly floods the desktop, with nothing in the release notes and no error anywhere. Either honouring the two hints (mako's `x-canonical-private-synchronous`, dunst's `x-dunst-stack-tag`) as replacement keys, or an explicit line in the 4.0 notes saying they are gone and `replaces_id` is the way, would close it. Related, and filed separately as a PR because it is a plain spec-compliance bug rather than a compatibility call: `CloseNotification` does not remove the toast either — https://github.com/basecamp/omarchy/pull/7833. The two compound. A sender that used the hint to update and `CloseNotification` to clean up gets neither, which is how the stack ends up permanent.
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:25 UTC