Filed for @spencerbull. Reproduced on my machine (dev-linked checkout), 2026-09-27.

## Summary

`bin/omarchy-sudo-passwordless` hardcodes its privileged half to
`/usr/bin/omarchy-sudo-passwordless` (`INSTALLED_SELF`, line 33). That fixed path is
correct for a packaged system, but on a `omarchy dev link`ed checkout the unprivileged
UI half runs from the checkout while the root half runs the **packaged** copy. On this
machine the packaged copy predates the whole hardened-grant rewrite and does not
understand `__status`, so every invocation dies with:

```
Toggle passwordless sudo...
Usage: omarchy-sudo-passwordless [MINUTES]
Could not safely inspect passwordless sudo; no grant will be enabled. Resolve the reported authorization or cleanup error first.
```

The `Usage:` line comes from the *legacy* script (`/usr/bin/omarchy-sudo-passwordless`),
whose first action is `[[ $1 && ! $1 =~ ^[0-9]+$ ]]` → reject `__status` → `exit 1`.
`1 != STATUS_INACTIVE (3)`, so the fail-closed rule in the UI (`--status` results other
than `3` are errors) turns a version-skew install problem into a generic
"authorization or cleanup error" message. There is no hint that the two halves are
different programs.

## Environment

```
$ omarchy version            dev (731fc8d0)          # omarchy dev link ~/omarchy
$ cat /etc/omarchy.conf      export OMARCHY_PATH="/home/jacob/omarchy"
$ echo $PATH                 ...:/home/jacob/omarchy/bin:...   # checkout first
$ pacman -Q omarchy omarchy-settings
omarchy 4.0.4-1
omarchy-settings 4.0.4-2
```

## Evidence

| Component | Expected | Actual |
|---|---|---|
| `/usr/bin/omarchy-sudo-passwordless` | checkout copy (16 227 B, supports `__status/__enable/__disable/__expire/__migrate/__cleanup-all/__package-removing`) | legacy 2 558 B script, owned by `omarchy 4.0.4-1`, dated Sep 15 |
| `/usr/bin/omarchy-security-functions` | installed next to the entrypoint (the helper `source`s `"${security_entrypoint%/*}/omarchy-security-functions"`) | **does not exist**, owned by no package |
| `/etc/tmpfiles.d/omarchy-nopasswd-sudo.conf` | `r! /etc/sudoers.d/99-omarchy-nopasswd-*` | OK, owned by `omarchy-settings 4.0.4-2` |
| `/usr/share/libalpm/hooks/05-omarchy-passwordless-revoke.hook` | installed by the settings package (`verify_boot_cleanup` compares it byte for byte) | **does not exist**, owned by no package (`pacman -Qo` → nothing) |
| `/var/lib/omarchy/migrations/1788163635` | empty root-owned marker | OK |

Hashes:

```
177c334ebd74…  /usr/bin/omarchy-sudo-passwordless            # legacy
177c334ebd74…  /usr/share/omarchy/bin/omarchy-sudo-passwordless   # legacy
0b41c36144c9…  ~/omarchy/bin/omarchy-sudo-passwordless       # hardened
```

Direct reproduction, no root needed (the legacy script rejects the action before it
ever calls `sudo`):

```
$ /usr/bin/omarchy-sudo-passwordless __status 1000
Usage: omarchy-sudo-passwordless [MINUTES]
$ echo $?
1
```

### The stale copy is not inert — it silently grants unbounded root

While reproducing this, an accidental invocation of `/usr/bin/omarchy-sudo-passwordless`
(the packaged legacy copy, no arguments) ran its legacy enable flow to completion:

```
Running timer as unit: omarchy-nopasswd-expire-jacob.timer
Passwordless sudo has been ENABLED. It will automatically disable in 15 minutes.

$ sudo cat /etc/sudoers.d/99-omarchy-nopasswd-jacob
jacob ALL=(ALL) NOPASSWD: ALL          # no NOTAFTER, unbounded
```

At that same moment the hardened UI half reported the grant as *confirmed inactive*:

```
$ sudo /usr/bin/omarchy-sudo-passwordless __status 1000
$ echo $?
3
```

because `read_grant`/`status_locked` only look at the **uid-named** file
(`99-omarchy-nopasswd-1000`) and never scan the rest of the reserved
`99-omarchy-nopasswd-*` namespace, where the legacy `-jacob` rule was living. So the UI
correctly refused to enable anything, while an unbounded `NOPASSWD: ALL` was live and
`__status` vouched that none existed. The legacy cleanup/quarantine logic that would have
caught it only runs from `__migrate` and `__cleanup-all`, neither of which the status path
calls. This is the security-relevant part of the bug: `STATUS_INACTIVE` is presented as
"confirmed inactive access" (`docs/passwordless-sudo.md`) but it means "no *new-style*
grant for my uid".

## Secondary defect: the hardened feature is not installable at all

This is not only a dev-mode problem. The packaged `omarchy` runtime still ships the
**legacy** helper at both `/usr/bin/omarchy-sudo-passwordless` and
`/usr/share/omarchy/bin/omarchy-sudo-passwordless`, `omarchy-security-functions` is
installed nowhere, and the pre-transaction revocation hook that `docs/passwordless-sudo.md`
("Package ownership") requires to ship **with** those files in the settings package is in
no package. So:

* a stock system runs the old, unbounded `NOPASSWD: ALL` writer;
* the hardened writer can only be reached from a checkout, where its own
  `verify_boot_cleanup` fails closed because the hook file is absent — so even after
  syncing the two copies, `__enable` returns `1` silently and the user gets the same
  unhelpful message.

`docs/passwordless-sudo.md` already states the invariant ("The packaging companion must
put the publication/expiry command, `omarchy-security-functions`,
`omarchy-nopasswd-sudo.conf`, and the pre-transaction revocation hook in the settings
package together"); the companion does not satisfy it.

## Why `omarchy dev link` does not cover this

`bin/omarchy-dev-link` (lines 17–24) rewrites root's `secure_path` to include
`$target/bin` so that `sudo omarchy-*` resolves to the checkout — but that only applies
to **bare command names**. `sudo /usr/bin/omarchy-sudo-passwordless …` is an absolute
path, so it bypasses `secure_path` entirely and silently executes the packaged copy. The
link's own comment describes exactly this failure ("one the package does not ship yet
fails outright, and one it does ship silently runs the packaged copy") and then the
passwordless command does it anyway. Its usage text also warns that fixed system paths
need `omarchy dev pkg-test`, which on a machine without `~/Work/omarchy/omarchy-pkgs` is
not available.

## Reproduction

1. `omarchy dev link ~/omarchy` (any checkout at or after `945af75a`).
2. Confirm `pacman -Q omarchy` is older than the checkout's rewrite of the file.
3. `omarchy sudo passwordless` → the two-line error above.
4. Same failure with no sudo timestamp caching involved (`sudo -k` first), so it is not
   an askpass/TTY artifact.

## Suggested fixes

1. **Ship the privileged pair atomically.** Move `/usr/bin/omarchy-sudo-passwordless` out
   of the runtime package and into the settings package together with
   `/usr/bin/omarchy-security-functions`, `/etc/tmpfiles.d/omarchy-nopasswd-sudo.conf`,
   and `/usr/share/libalpm/hooks/05-omarchy-passwordless-revoke.hook`, per
   `docs/passwordless-sudo.md`. Add a `checkdepends`/package-time assertion so the four
   files can never be split, and cover it in the existing source/package lock test.
2. **Make dev mode honest about fixed system paths.** Either have `omarchy dev link`
   install (and `omarchy dev unlink` remove) the checkout's helper + functions + hook at
   those fixed paths, or refuse to link a checkout whose `bin/omarchy-sudo-passwordless`
   differs from `/usr/bin`'s, telling the user to run `omarchy dev pkg-test`. Keep
   `INSTALLED_SELF` fixed — the point of shipping it at a root-owned path is that the
   calling user cannot swap it. If you do want a dev override, resolve it **only** from
   the root-owned `/etc/omarchy.conf` (never from the caller's `PATH`/`$OMARCHY_PATH`)
   and note that it hands root execution of a user-writable file, which is the same
   trust `secure_path` already extends in dev mode, not something to add for packaged
   systems.
3. **Fail loudly on pairing skew, before touching sudo.** Add a `__protocol` (or
   `__pairing`) internal action returning a protocol integer plus which required
   component is missing/stale (helper hash, functions file, boot cleanup rule, hook).
   The UI should print the actionable sentence, e.g. "`/usr/bin/omarchy-sudo-passwordless`
   is older than your checkout (177c334e… vs 0b41c361…): run `omarchy dev pkg-test`" or
   "the revocation hook `/usr/share/libalpm/hooks/05-…` is missing; reinstall
   `omarchy-settings`". Keep these distinct from the `STATUS_INACTIVE` (3) result — the
   current code correctly refuses to downgrade an inspection failure to "no grant", it
   just discards the cause.
4. **Don't let a legacy `/usr/bin` copy masquerade as the hardened one.** A cheap probe
   (`__status` answered with the legacy usage text, or a protocol action the legacy copy
   cannot answer) distinguishes "stale package" from "authorization failure".
5. **`__status` must account for the whole reserved prefix.** Before returning
   `STATUS_INACTIVE`, scan `99-omarchy-nopasswd-*` for legacy/foreign rules (or run the
   migration/quarantine pass inline) and return a distinct result when an unbounded grant
   exists that the command did not create. `3` currently over-promises, and the UI's
   "only offer a grant after 3" rule is only as sound as that claim.
6. **Tests.** In `test/shell.d/passwordless-grant-lifecycle-test.sh`, add a case where the
   installed helper is the legacy copy while the UI is hardened, and assert the error
   names the mismatch and exits non-zero without writing anything under `etc/sudoers.d`.
   Assert the four-file pairing invariant from the built packages, and the
   `omarchy-settings` ↔ `omarchy-settings-dev` ownership transfer in one transaction.

## Handoff instructions

```bash
cd ~/omarchy                       # dev-linked checkout, 731fc8d0
git log --oneline -8 -- bin/omarchy-sudo-passwordless
sed -n '28,40p;330,340p;410,432p' bin/omarchy-sudo-passwordless   # INSTALLED_SELF, systemd-run, the sudo -N block
sed -n '10,30p;95,110p' bin/omarchy-dev-link                       # secure_path comment
cat docs/passwordless-sudo.md                                      # "Package ownership" and "Validation"
OMARCHY_PKGS_PATH=<path-to-pkgs> bash test/shell.d/passwordless-grant-lifecycle-test.sh
```

Checklist for the fix:

- [ ] packaging companion: helper + `omarchy-security-functions` + tmpfiles rule + `05-omarchy-passwordless-revoke.hook` in **one** package (settings), removed from the runtime package
- [ ] `omarchy dev link` / `unlink` (or `dev pkg-test`) keep the fixed-path privileged half in step with the checkout, and `omarchy dev link --help` says which layers it does not cover for this command
- [ ] preflight pairing/protocol check with distinct, actionable error text; `STATUS_INACTIVE` still the only "no grant" signal
- [ ] legacy-copy detection so a stale package cannot be mistaken for an authorization failure
- [ ] `__status` reports a legacy/unbounded grant under the reserved prefix instead of returning `3`
- [ ] tests above, plus a fresh-VM validation pass for boot cleanup and package removal (the "Validation" section already requires it)
- [ ] docs: record in `docs/passwordless-sudo.md` that the command's root half is a fixed-path, package-owned file and how dev mode must supply it

## Local workaround in use on this machine

`~/.local/bin/omarchy-dev-sync-sudo-helper` installs the checkout's copies at the fixed
paths and self-tests the root half. `--check` reports the pairing state; the install path
is:

```bash
sudo install -Dm755 -o root -g root ~/omarchy/bin/omarchy-sudo-passwordless    /usr/bin/omarchy-sudo-passwordless
sudo install -Dm755 -o root -g root ~/omarchy/bin/omarchy-security-functions   /usr/bin/omarchy-security-functions
sudo install -Dm644 -o root -g root ~/omarchy/default/libalpm/hooks/05-omarchy-passwordless-revoke.hook /usr/share/libalpm/hooks/05-omarchy-passwordless-revoke.hook
```

Unowned-file caveat: these three paths stay owned by nothing until the packaging fix
lands, `pacman -Qk` will flag the first, and any `omarchy` package upgrade reverts it.