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 #8638

Activity

1. Andor4225 commented on Sep 26, 2026

   

   Andor4225

   on Sep 26, 2026

   More actions

   Still unmigrated as of omarchy 4.0.4-1 (stable channel), a month after this was filed against 4.0.1 — so the ~/.config copies are still being left behind. Confirming independently, and with a data point for the "related detail" about the burned markers, since that is the part that does lasting damage.

   This machine's timeline makes the mechanism explicit:

   Time (2026-09-22)	Event
   16:18	first-run installs the three invitation hooks into ~/.config/omarchy/hooks/post-update.d/ with the quoted --exec form
   16:25	omarchy package upgraded to 4.0.4-1
   16:29:05	first post-update hook run — all three omarchy-done markers created, all three notifications fail

   All three markers are stamped within 17 ms of each other:

   2026-09-22 16:29:05.131  voxtype-install-invitation
   2026-09-22 16:29:05.145  agent-setup-invitation
   2026-09-22 16:29:05.162  fingerprint-setup-invitation
   

   One pass armed every marker and delivered nothing. Worth stressing what you already noted: fixing the --exec quoting alone is not sufficient for anyone already past this point. I corrected the quoting in all three hooks and nothing appeared, because ensure had already consumed the markers. The invitations only came back after deleting them.

   To confirm the rejection is what breaks the hooks, on 4.0.4:

   $ omarchy-notification-send -u low -g X T B --exec "omarchy menu summon setup.default.agent"; echo $?
   --exec takes the command as separate words, not one quoted string.
   1
   $ omarchy-notification-send -u low -g X T B --exec omarchy menu summon setup.default.agent; echo $?
   0

   Note the templates in /usr/share/omarchy/install/user/first-run/ are correct in 4.0.4 — all three use separate words. It is purely the already-installed user copies that are stranded, which matches your diagnosis.

   A one-line variant of the failure-safe fix

   Gating the mark on delivery needs the ensure/notify order inverted. If a smaller change is preferable, re-arming on failure is a single appended line per hook and keeps ensure where it is:

   if omarchy-done ensure voxtype-install-invitation; then
     omarchy-notification-send -u critical -g  "Install Dictation with Voxtype" \
       "Click to install voice dictation for Omarchy." \
       --exec omarchy-launch-floating-terminal-with-presentation omarchy-voxtype-install ||
       rm -f "$HOME/.local/state/omarchy/done/voxtype-install-invitation"
   fi

   A failed send then leaves no marker, so the next omarchy update retries instead of losing the invitation. Verified both ways here: with a stub omarchy-notification-send that exits 1 the marker is absent afterwards; with the real one the notification appears and the marker is set so it does not nag again.

   This also covers failure modes unrelated to --exec — a notification daemon not yet up when the hook runs would burn the invitation just as permanently.

   System

   Omarchy 4.0.4-1 (stable), Hyprland 0.56.2, AMD laptop (Ryzen + Radeon integrated), fresh 4.0.x install.

   Unrelated but adjacent, in case it helps date things: /usr/share/omarchy/version still reads 4.0.0.alpha on this 4.0.4-1 package, which is #8246.
2. omarchybot

   added

   bugSomething isn't workingSomething isn't working

   on Sep 27, 2026
3. omarchybot commented on Oct 9, 2026

   

   omarchybot

   on Oct 9, 2026

   Collaborator

   More actions

   Confirmed on current quattro (c352b62), and open PR #8399 fixes the quoting. I've linked it here, so this issue closes when that PR merges.

   What was checked. I copied the three hooks exactly as 4.0.0 shipped them (git show v4.0.0:install/user/first-run/*.hook) into a clean HOME on a disposable worker built from the Omarchy ISO, and ran them against quattro's bin/. The D-Bus send was stubbed, so a pass only means the hook got past argument checking. All three exit 1 with --exec takes the command as separate words, not one quoted string. (bin/omarchy-notification-send:171). Nothing on quattro rewrites the user copies: migrations/1786549201.sh reinstalls the agent hook, but it already shipped in 4.0.0, so those installs have already run it.

   #8399. Its migration rewrites the three exact strings 4.0.0 shipped. With that migration applied to the same files, all three hooks exit 0. bin/omarchy-migrate runs any migration it has not run before, by filename, and omarchy-update runs migrations before post-update hooks, so the repair takes effect in the same update that delivers it.

   What #8399 does not fix:

   • Burned markers. As both of you found, omarchy-done ensure creates the marker before the notification is sent (install/user/first-run/setup-agent.hook:7, setup-fingerprint.hook:8). So each hook fails once, and after that it skips silently instead of failing every time. On the worker, hooks migrated after that first failure exit 0 and send nothing. The current templates still claim the marker first, so any future send failure loses the invitation the same way. Deciding whether to re-arm markers that have already been burned is a product call for the maintainer: an empty marker cannot tell a delivered invitation from a failed one, so resetting them could repeat invitations people have already seen.
   • The Voxtype invitation. On quattro, omarchy-voxtype-install is gone (it is now omarchy-install-dictation-voxtype). After Migrate invitation hooks to notification argv #8399 the Voxtype hook passes argument checking, but clicking it would run a command that no longer exists. Open PR Preserve legacy dictation choices during Quattro upgrades #14654 retires that hook, but only when it matches the 4.0.1+ text byte for byte. If both PRs land in the same update, Migrate invitation hooks to notification argv #8399's migration runs first and the hook is removed; I checked that on the worker. If Preserve legacy dictation choices during Quattro upgrades #14654 ships first, a stock 4.0.0 Voxtype hook is never removed.

   The second opinion was Codex at Medium effort. It agreed with the mechanism and the fix. It also contributed two points I hadn't reasoned through: the fail-once-then-silent behaviour, and the #14654-first ordering problem. Independence is not guaranteed.

   Next: this waits on the maintainer, who decides whether to merge #8399, how it should land alongside #14654, and what to do about markers that are already burned. #8399 will be reviewed as its own item.