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

Quattro upgrade enables SDDM auto-login on LUKS systems, preventing GNOME Keyring auto-unlock

Reported by vikrant0017 · filed Aug 29, 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

Quattro upgrade enables SDDM auto-login on LUKS systems, preventing GNOME Keyring auto-unlockrevision 1 · captured 2026-09-28 21:24 UTC via poll

Regression

After upgrading to Omarchy 4.0.0-1, SDDM auto-login was enabled on my LUKS-encrypted system. This prevents pam_gnome_keyring from receiving my account password, so GNOME Keyring cannot unlock at session start. Applications such as Chromium and editors consequently prompt for the keyring password individually.

Evidence

The upgrade installed Omarchy 4.0.0-1 at 2026-08-16 15:46:32 IST. Seconds later, it created this unowned file:

/etc/sddm.conf.d/autologin.conf (mtime: 2026-08-16 15:47:48 IST)

[Autologin]
User=vikrant
Session=omarchy.desktop

The installed omarchy-upgrade-to-quattro script explicitly enables SDDM auto-login when the root filesystem is encrypted. This machine uses LUKS:

/dev/mapper/root[/@] btrfs
nvme0n1p2 crypto_LUKS
└─root crypt btrfs

At login, the session is reported as sddm-autologin, and the journal records:

gkr-pam: no password is available for user

The normal SDDM PAM configuration includes pam_gnome_keyring.so, but an auto-login session has no password for it to pass through.

Expected behavior

An upgrade should preserve a password-based SDDM login, or explicitly offer/configure that choice, when auto-login would prevent GNOME Keyring from unlocking automatically.

Actual behavior

The migration enables auto-login on an encrypted-root system. Apps then prompt separately for the keyring password throughout the session.

Notes

GNOME Keyring also has a separate upstream crash in this environment while servicing Secret Service requests. This report is specifically about Omarchy’s migration/configuration causing the loss of automatic keyring unlocking.

Omarchy version: 4.0.0-1

omarchy debug --no-sudo --print is not available in this installed version.

Filed by GPT-5 via Codex.

View raw text
## Regression

After upgrading to Omarchy 4.0.0-1, SDDM auto-login was enabled on my LUKS-encrypted system. This prevents `pam_gnome_keyring` from receiving my account password, so GNOME Keyring cannot unlock at session start. Applications such as Chromium and editors consequently prompt for the keyring password individually.

## Evidence

The upgrade installed Omarchy 4.0.0-1 at 2026-08-16 15:46:32 IST. Seconds later, it created this unowned file:

`/etc/sddm.conf.d/autologin.conf` (mtime: 2026-08-16 15:47:48 IST)

```ini
[Autologin]
User=vikrant
Session=omarchy.desktop
```

The installed `omarchy-upgrade-to-quattro` script explicitly enables SDDM auto-login when the root filesystem is encrypted. This machine uses LUKS:

```text
/dev/mapper/root[/@] btrfs
nvme0n1p2 crypto_LUKS
└─root crypt btrfs
```

At login, the session is reported as `sddm-autologin`, and the journal records:

```text
gkr-pam: no password is available for user
```

The normal SDDM PAM configuration includes `pam_gnome_keyring.so`, but an auto-login session has no password for it to pass through.

## Expected behavior

An upgrade should preserve a password-based SDDM login, or explicitly offer/configure that choice, when auto-login would prevent GNOME Keyring from unlocking automatically.

## Actual behavior

The migration enables auto-login on an encrypted-root system. Apps then prompt separately for the keyring password throughout the session.

## Notes

GNOME Keyring also has a separate upstream crash in this environment while servicing Secret Service requests. This report is specifically about Omarchy’s migration/configuration causing the loss of automatic keyring unlocking.

Omarchy version: 4.0.0-1

`omarchy debug --no-sudo --print` is not available in this installed version.

Filed by GPT-5 via Codex.

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