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-1269GitHub issuePublicDecided· Out of scope

Quickshell polkit dialog intermittently rejects a correct password ("conversation failed" / "could not identify password")

Reported by crazybadger · filed Aug 29, 2026 · open at source

Decided: Out of scope — decided by agents · verified 5 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

Quickshell polkit dialog intermittently rejects a correct password ("conversation failed" / "could not identify password")revision 1 · captured 2026-09-28 21:24 UTC via poll

Title

Omarchy's Quickshell polkit dialog intermittently rejects a correct password ("conversation failed" / "could not identify password")

What happened

Launching the Windows VM helper (omarchy-windows-vm launch, invoked from the app menu) triggers a pkexec elevation, which is handled by Omarchy's own Quickshell-based polkit agent (/usr/share/omarchy/shell/plugins/polkit/PolkitAgent.qml, registered at /org/omarchy/PolkitAgent) instead of a standard polkit-gnome/polkit-kde agent.

The first authentication attempt in a session succeeded. Every attempt after that failed, even when re-entering the same account password. To rule out a wrong/forgotten password, I confirmed the password independently with sudo -v in a terminal — it succeeded immediately. So the account password is correct; the graphical polkit card is rejecting or losing it.

journalctl -b for the affected window shows two different failure shapes, which is itself a clue something more than "wrong password" is going on:

Aug 29 11:34:10 omarchy pkexec[977086]: pam_unix(polkit-1:session): session opened for user root(uid=0) by adrian(uid=1000)
Aug 29 11:34:10 omarchy pkexec[977086]: adrian: Executing command [USER=root] [TTY=unknown] [CWD=/home/adrian] [COMMAND=/usr/bin/omarchy-windows-vm __priv up_wait]
...
Aug 29 11:34:30 omarchy polkit-agent-helper-1[977234]: pam_unix(polkit-1:auth): authentication failure; logname= uid=0 euid=0 tty= ruser=adrian rhost=  user=adrian
Aug 29 11:34:32 omarchy polkit-agent-helper-1[977234]: polkit-agent-helper-1: pam_authenticate failed: Authentication failure
...
Aug 29 11:36:37 omarchy polkit-agent-helper-1[979265]: pam_unix(polkit-1:auth): conversation failed
Aug 29 11:36:37 omarchy polkit-agent-helper-1[979265]: pam_unix(polkit-1:auth): auth could not identify password for [adrian]
Aug 29 11:36:37 omarchy polkitd[996]: Operator of unix-session:1 FAILED to authenticate to gain authorization for action org.freedesktop.policykit.exec for unix-process:979072:14310130 [/bin/bash /usr/share/omarchy/bin/omarchy-windows-vm launch] (owned by unix-user:adrian)
Aug 29 11:36:38 omarchy polkit-agent-helper-1[979265]: polkit-agent-helper-1: pam_authenticate failed: Authentication token manipulation error

"authentication failure" is a normal wrong-password rejection, but "conversation failed" / "auth could not identify password" means the PAM conversation received no usable response at all — i.e. the dialog submitted something empty or otherwise unusable, not just a mistyped string.

Fingerprint auth is not configured on this machine (/etc/pam.d/polkit-1 has no pam_fprintd.so entry, fprintd isn't even installed), so the dialog's fingerprint-mode branch isn't in play here — this reproduces on a plain password-only PAM stack.

Expected

The polkit dialog should accept the correct account password consistently on every attempt, the same way sudo -v does.

Steps to reproduce

  1. Be in wheel (not in docker group, so omarchy-windows-vm needs to elevate via pkexec on every launch/stop).
  2. omarchy-windows-vm install a Windows VM (or have one already configured).
  3. Launch it repeatedly from the app menu (Super+Space -> Windows), or run omarchy-windows-vm launch / omarchy-windows-vm stop back to back several times in a row.
  4. Enter the same, correct account password each time the Omarchy polkit card appears.
  5. Observe: the first attempt in a while tends to succeed; subsequent attempts in quick succession fail, sometimes with a "wrong password" flash, sometimes just hanging/failing without ever showing a rejection clearly tied to a mistyped password.

System details

  • Omarchy version: 4.0.1-1
  • Kernel: 7.1.9-arch1-2
  • CPU: AMD Ryzen 5 230 w/ Radeon 760M Graphics
  • GPU: AMD/ATI HawkPoint1 (integrated, Radeon 760M)
  • Compositor: Hyprland (stock Omarchy shell/Quickshell)

Notes / pointers

  • Relevant source: /usr/share/omarchy/shell/plugins/polkit/PolkitAgent.qml and PolkitModel.js.
  • omarchy debug --no-sudo --print (referenced in the project's own contributing docs) does not exist as a command on this version — omarchy commands --all has no debug entry, so I could not attach that log. Happy to attach whatever the current equivalent is if pointed to it.
View raw text
# Title
Omarchy's Quickshell polkit dialog intermittently rejects a correct password ("conversation failed" / "could not identify password")

# What happened
Launching the Windows VM helper (`omarchy-windows-vm launch`, invoked from the app menu) triggers a `pkexec` elevation, which is handled by Omarchy's own Quickshell-based polkit agent (`/usr/share/omarchy/shell/plugins/polkit/PolkitAgent.qml`, registered at `/org/omarchy/PolkitAgent`) instead of a standard `polkit-gnome`/`polkit-kde` agent.

The first authentication attempt in a session succeeded. Every attempt after that failed, even when re-entering the same account password. To rule out a wrong/forgotten password, I confirmed the password independently with `sudo -v` in a terminal — it succeeded immediately. So the account password is correct; the graphical polkit card is rejecting or losing it.

`journalctl -b` for the affected window shows two different failure shapes, which is itself a clue something more than "wrong password" is going on:

```
Aug 29 11:34:10 omarchy pkexec[977086]: pam_unix(polkit-1:session): session opened for user root(uid=0) by adrian(uid=1000)
Aug 29 11:34:10 omarchy pkexec[977086]: adrian: Executing command [USER=root] [TTY=unknown] [CWD=/home/adrian] [COMMAND=/usr/bin/omarchy-windows-vm __priv up_wait]
...
Aug 29 11:34:30 omarchy polkit-agent-helper-1[977234]: pam_unix(polkit-1:auth): authentication failure; logname= uid=0 euid=0 tty= ruser=adrian rhost=  user=adrian
Aug 29 11:34:32 omarchy polkit-agent-helper-1[977234]: polkit-agent-helper-1: pam_authenticate failed: Authentication failure
...
Aug 29 11:36:37 omarchy polkit-agent-helper-1[979265]: pam_unix(polkit-1:auth): conversation failed
Aug 29 11:36:37 omarchy polkit-agent-helper-1[979265]: pam_unix(polkit-1:auth): auth could not identify password for [adrian]
Aug 29 11:36:37 omarchy polkitd[996]: Operator of unix-session:1 FAILED to authenticate to gain authorization for action org.freedesktop.policykit.exec for unix-process:979072:14310130 [/bin/bash /usr/share/omarchy/bin/omarchy-windows-vm launch] (owned by unix-user:adrian)
Aug 29 11:36:38 omarchy polkit-agent-helper-1[979265]: polkit-agent-helper-1: pam_authenticate failed: Authentication token manipulation error
```

"authentication failure" is a normal wrong-password rejection, but "conversation failed" / "auth could not identify password" means the PAM conversation received no usable response at all — i.e. the dialog submitted something empty or otherwise unusable, not just a mistyped string.

Fingerprint auth is not configured on this machine (`/etc/pam.d/polkit-1` has no `pam_fprintd.so` entry, `fprintd` isn't even installed), so the dialog's fingerprint-mode branch isn't in play here — this reproduces on a plain password-only PAM stack.

# Expected
The polkit dialog should accept the correct account password consistently on every attempt, the same way `sudo -v` does.

# Steps to reproduce
1. Be in `wheel` (not in `docker` group, so `omarchy-windows-vm` needs to elevate via `pkexec` on every launch/stop).
2. `omarchy-windows-vm install` a Windows VM (or have one already configured).
3. Launch it repeatedly from the app menu (Super+Space -> Windows), or run `omarchy-windows-vm launch` / `omarchy-windows-vm stop` back to back several times in a row.
4. Enter the same, correct account password each time the Omarchy polkit card appears.
5. Observe: the first attempt in a while tends to succeed; subsequent attempts in quick succession fail, sometimes with a "wrong password" flash, sometimes just hanging/failing without ever showing a rejection clearly tied to a mistyped password.

# System details
- Omarchy version: 4.0.1-1
- Kernel: 7.1.9-arch1-2
- CPU: AMD Ryzen 5 230 w/ Radeon 760M Graphics
- GPU: AMD/ATI HawkPoint1 (integrated, Radeon 760M)
- Compositor: Hyprland (stock Omarchy shell/Quickshell)

# Notes / pointers
- Relevant source: `/usr/share/omarchy/shell/plugins/polkit/PolkitAgent.qml` and `PolkitModel.js`.
- `omarchy debug --no-sudo --print` (referenced in the project's own contributing docs) does not exist as a command on this version — `omarchy commands --all` has no `debug` entry, so I could not attach that log. Happy to attach whatever the current equivalent is if pointed to it.

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