Proof Portal

Sign in
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-1553GitHub issuePublicDecided· Out of scope

omarchy pkg add/drop/aur add have no consistent way to use pkexec for non-interactive/agent-driven privilege escalation

Reported by bcelary · filed Aug 23, 2026 · open at source

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

omarchy pkg add/drop/aur add have no consistent way to use pkexec for non-interactive/agent-driven privilege escalationrevision 1 · captured 2026-09-28 21:24 UTC via poll

Summary

The skill/docs for agent-driven Omarchy usage say: "sudo when a terminal is available for the password prompt, pkexec when it is not." In practice, this only works for omarchy pkg add and omarchy pkg drop, and only by accident — omarchy pkg aur add can't be made to work this way at all without a script change, because the actual privileged step happens inside yay's own process, not at the top level.

What works today (and why it's fragile)

  • omarchy-pkg-add: checks EUID == 0 and calls pacman directly in that case, skipping its own sudo call. So pkexec omarchy-pkg-add <pkgs> works — but only because of this branch, which doesn't look like it was written with pkexec in mind.
  • omarchy-pkg-drop: always calls sudo pacman -Rns. pkexec omarchy-pkg-drop <pkgs> still works, but only because sudo is a no-op when the caller is already root (pam_rootok) — not because the script accounts for this case.

What's actually broken

  • omarchy-pkg-aur-add always calls yay -S --noconfirm --needed "$@". yay/makepkg refuse to run as root, so pkexec omarchy-pkg-aur-add <pkgs> is not just broken today — no fix to the wrapper's top-level invocation could ever make it safe. The actual privileged step (the final pacman -U after building) happens inside yay, after it's already dropped to build as the unprivileged user.

The pattern Omarchy already uses elsewhere

shell/plugins/panels/tailscale/Service.qml calls pkexec directly on the real privileged binary:

operatorProcess.command = ["pkexec", "tailscale", "set", "--operator=" + userName]

Never on a wrapper script that itself shells out to sudo. This is the right shape — pkexec has to reach the actual privileged operation, not an outer script.

Suggested fix

yay already exposes the right hook: --sudo <file>, letting it use an arbitrary escalation command for its internal privileged step. omarchy-pkg-aur-add could detect the no-TTY case ([[ ! -t 0 ]] or similar) and pass --sudo pkexec through automatically — reaching the real privileged step directly, the same principle the Tailscale panel already follows. For consistency, omarchy-pkg-add/omarchy-pkg-drop could do the same explicitly rather than relying on the EUID==0/pam_rootok accidents that happen to make them work today.

Context

Hit this while using an agent (Claude Code) to install packages non-interactively per the Omarchy skill's own privilege-escalation guidance — pkg add/pkg drop worked fine via pkexec, pkg aur add did not and required manually falling back to yay -S --sudo pkexec ... directly.

Environment

Omarchy 4.0.0

View raw text
### Summary

The skill/docs for agent-driven Omarchy usage say: *"sudo when a terminal is available for the password prompt, pkexec when it is not."* In practice, this only works for `omarchy pkg add` and `omarchy pkg drop`, and only by accident — `omarchy pkg aur add` can't be made to work this way at all without a script change, because the actual privileged step happens inside `yay`'s own process, not at the top level.

### What works today (and why it's fragile)

- `omarchy-pkg-add`: checks `EUID == 0` and calls `pacman` directly in that case, skipping its own `sudo` call. So `pkexec omarchy-pkg-add <pkgs>` works — but only because of this branch, which doesn't look like it was written with `pkexec` in mind.
- `omarchy-pkg-drop`: always calls `sudo pacman -Rns`. `pkexec omarchy-pkg-drop <pkgs>` still works, but only because `sudo` is a no-op when the caller is already root (`pam_rootok`) — not because the script accounts for this case.

### What's actually broken

- `omarchy-pkg-aur-add` always calls `yay -S --noconfirm --needed "$@"`. `yay`/`makepkg` refuse to run as root, so `pkexec omarchy-pkg-aur-add <pkgs>` is not just broken today — no fix to the wrapper's top-level invocation could ever make it safe. The actual privileged step (the final `pacman -U` after building) happens *inside* `yay`, after it's already dropped to build as the unprivileged user.

### The pattern Omarchy already uses elsewhere

`shell/plugins/panels/tailscale/Service.qml` calls `pkexec` directly on the real privileged binary:
```qml
operatorProcess.command = ["pkexec", "tailscale", "set", "--operator=" + userName]
```
Never on a wrapper script that itself shells out to `sudo`. This is the right shape — `pkexec` has to reach the *actual* privileged operation, not an outer script.

### Suggested fix

`yay` already exposes the right hook: `--sudo <file>`, letting it use an arbitrary escalation command for its internal privileged step. `omarchy-pkg-aur-add` could detect the no-TTY case (`[[ ! -t 0 ]]` or similar) and pass `--sudo pkexec` through automatically — reaching the real privileged step directly, the same principle the Tailscale panel already follows. For consistency, `omarchy-pkg-add`/`omarchy-pkg-drop` could do the same explicitly rather than relying on the `EUID==0`/`pam_rootok` accidents that happen to make them work today.

### Context

Hit this while using an agent (Claude Code) to install packages non-interactively per the Omarchy skill's own privilege-escalation guidance — `pkg add`/`pkg drop` worked fine via `pkexec`, `pkg aur add` did not and required manually falling back to `yay -S --sudo pkexec ...` directly.

### Environment

Omarchy 4.0.0

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:28 UTC