Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-1348GitHub issuePublicDecided· Out of scope

4.0.1 breaks the invitation hooks 4.0.0 installed in user config: omarchy-notification-send --exec rejects the old quoted form, no migration

Reported by tecnarchico · filed Aug 27, 2026 · open at source

Decided: Out of scope — decided by agents · verified 4 days ago.

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

4.0.1 breaks the invitation hooks 4.0.0 installed in user config: omarchy-notification-send --exec rejects the old quoted form, no migrationrevision 1 · captured 2026-09-28 21:24 UTC via poll

What happened

Updating 4.0.0-1 → 4.0.1-1, the post-update hooks failed:

--exec takes the command as separate words, not one quoted string.
Write:  --exec omarchy-launch-floating-terminal-with-presentation omarchy-voxtype-install
Hook failed: /home/<user>/.config/omarchy/hooks/post-update.d/install-voxtype.hook

The failing hooks were not written by me — they are the first-run invitation hooks Omarchy 4.0.0 itself installed into ~/.config/omarchy/hooks/post-update.d/ (install-voxtype.hook, setup-agent.hook, setup-fingerprint.hook), which at the time used the then-valid quoted form:

--exec "omarchy-launch-floating-terminal-with-presentation omarchy-voxtype-install"

4.0.1 tightened omarchy-notification-send to require --exec <program> [args...] as separate argv words and updated its own templates in /usr/share/omarchy/install/user/first-run/ to the new form — but the copies already installed in users' ~/.config were left behind, so they now fail on every post-update run. Presumably every 4.0.0 install that hasn't seen these invitations yet hits this.

What I expected

A migration that rewrites the previously shipped hook contents to the new --exec form (the same update was already running other migrations), or omarchy-notification-send accepting the legacy single-string form with a deprecation warning for one release.

Related detail worth fixing at the same time

The invitation hooks call omarchy-done ensure <marker> before sending the notification. ensure creates the marker as its check, so when omarchy-notification-send then fails, the one-shot marker is already burned — the invitation is lost forever even after the hook is fixed. (In my case voxtype-install-invitation was marked done by the failed run; I had to delete the marker manually to ever see the invite.) Marking done only after the notification succeeds would make these hooks failure-safe.

Reproduction

  1. Install Omarchy 4.0.0 (first-run installs the invitation hooks into ~/.config/omarchy/hooks/post-update.d/ with the quoted --exec form).
  2. omarchy update to 4.0.1.
  3. Post-update hook run fails as above; the touched omarchy-done markers are burned.

System

  • Omarchy 4.0.0-1 → 4.0.1-1, hyprland 0.56.2-1
  • CPU: Intel Core i7-14650HX; GPU: Intel Raptor Lake-S UHD + NVIDIA RTX 4080 Max-Q (hybrid)
View raw text
## What happened

Updating 4.0.0-1 → 4.0.1-1, the post-update hooks failed:

```
--exec takes the command as separate words, not one quoted string.
Write:  --exec omarchy-launch-floating-terminal-with-presentation omarchy-voxtype-install
Hook failed: /home/<user>/.config/omarchy/hooks/post-update.d/install-voxtype.hook
```

The failing hooks were not written by me — they are the first-run invitation hooks Omarchy 4.0.0 itself installed into `~/.config/omarchy/hooks/post-update.d/` (`install-voxtype.hook`, `setup-agent.hook`, `setup-fingerprint.hook`), which at the time used the then-valid quoted form:

```bash
--exec "omarchy-launch-floating-terminal-with-presentation omarchy-voxtype-install"
```

4.0.1 tightened `omarchy-notification-send` to require `--exec <program> [args...]` as separate argv words and updated its own templates in `/usr/share/omarchy/install/user/first-run/` to the new form — but the copies already installed in users' `~/.config` were left behind, so they now fail on every post-update run. Presumably every 4.0.0 install that hasn't seen these invitations yet hits this.

## What I expected

A migration that rewrites the previously shipped hook contents to the new `--exec` form (the same update was already running other migrations), or `omarchy-notification-send` accepting the legacy single-string form with a deprecation warning for one release.

## Related detail worth fixing at the same time

The invitation hooks call `omarchy-done ensure <marker>` *before* sending the notification. `ensure` creates the marker as its check, so when `omarchy-notification-send` then fails, the one-shot marker is already burned — the invitation is lost forever even after the hook is fixed. (In my case `voxtype-install-invitation` was marked done by the failed run; I had to delete the marker manually to ever see the invite.) Marking done only after the notification succeeds would make these hooks failure-safe.

## Reproduction

1. Install Omarchy 4.0.0 (first-run installs the invitation hooks into `~/.config/omarchy/hooks/post-update.d/` with the quoted `--exec` form).
2. `omarchy update` to 4.0.1.
3. Post-update hook run fails as above; the touched `omarchy-done` markers are burned.

## System

- Omarchy 4.0.0-1 → 4.0.1-1, hyprland 0.56.2-1
- CPU: Intel Core i7-14650HX; GPU: Intel Raptor Lake-S UHD + NVIDIA RTX 4080 Max-Q (hybrid)

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 09:36 UTC