Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA 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.
1Password autostart entry lacks --force-device-scale-factor=1, so windows mis-render when text size != 12px (default on XPS 13)
Reported by jnstq · filed Sep 17, 2026 · open at source
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
Description
1Password windows render their content at the GTK text-scaling-factor instead of the monitor scale when it is started from its own "Start at login" autostart entry, because that entry does not carry the --force-device-scale-factor=1 pin that Omarchy applies everywhere else.
With omarchy display text size 11 (which is the stock default on Dell XPS 13 via install/user/hardware/dell/xps13-text-scaling.sh), the GTK factor becomes 0.9091. 1Password, being Electron, derives its device scale factor from that and draws its content at 0.909× while the Wayland surface keeps its full logical size. The result is a dialog that only fills ~90% of its window, with whatever is behind it visible in the gap (screenshot attached: the SSH-agent authorization dialog with a foot terminal showing through the right/bottom edge).
Knock-on effect: the SSH authorization dialog is where you type the account password when 1Password is locked. In my case the mis-rendered prompt led to failed unlock attempts, the SSH authorization request timed out, and ssh/git failed with agent refused operation.
Root cause
Omarchy already pins the scale in two places:
/usr/share/applications/1password.desktop(Omarchy package1password 8.12.36-2):Exec=/opt/1Password/1password --force-device-scale-factor=1 %Ubin/omarchy-launch-1password:exec setsid uwsm-app -- 1password --force-device-scale-factor=1
But when "Start 1Password at login" is enabled in 1Password's settings, 1Password writes its own ~/.config/autostart/com.onepassword.OnePassword.desktop with:
Exec=/opt/1Password/1password --silentThat is the instance that runs for the whole session, and it has no scale pin, so neither of Omarchy's fixes apply. omarchy-install-service-1password doesn't touch the autostart entry either.
Steps to reproduce
- Install 1Password (
omarchy install service 1password) and enable Settings → General → Start 1Password at login (or be on an XPS 13, where text size 11 is the default). omarchy display text size 11- Log out and back in so 1Password starts from the autostart entry.
- Open any 1Password window (e.g. trigger an SSH key authorization, or SUPER+SHIFT+/ — the main window is affected too as long as the
--silentinstance is the one that owns the windows).
Expected: the window content fills the window, as it does when launched via omarchy-launch-1password.
Actual: content is drawn at ~0.91× in the top-left of the window with a transparent gap on the right/bottom.
Verified: pgrep -a 1password showed /opt/1Password/1password --silent (no flag). Killing it and relaunching with --force-device-scale-factor=1 --silent fixes the rendering immediately.
Proposed fix
Patch the autostart entry whenever Omarchy touches 1Password, and once for existing installs via a migration. Something like:
# bin/omarchy-install-service-1password (after omarchy-pkg-add) and a new migration
autostart="$HOME/.config/autostart/com.onepassword.OnePassword.desktop"
if [[ -f $autostart ]] && ! grep -q -- '--force-device-scale-factor' "$autostart"; then
sed -i -E 's|^(Exec=/opt/1Password/1password)|\1 --force-device-scale-factor=1|' "$autostart"
fiCaveat for the fix: 1Password rewrites this file when the "Start at login" toggle is flipped, so the pin can be lost again. A more robust alternative would be for Omarchy to ship its own autostart entry (e.g. ~/.config/autostart/1password.desktop pointing at omarchy-launch-1password --silent) and tell users to leave 1Password's own toggle off — but that is a bigger change; the sed patch above covers the common case.
Workaround for users hitting this now:
sed -i 's|^Exec=/opt/1Password/1password --silent$|Exec=/opt/1Password/1password --force-device-scale-factor=1 --silent|' \
~/.config/autostart/com.onepassword.OnePassword.desktop
pkill -x 1password; setsid uwsm-app -- /opt/1Password/1password --force-device-scale-factor=1 --silentSystem
- Omarchy 4.0.4-1, kernel 7.2.5-3-omarchy
- Dell XPS 13, Intel Core 5 320, Intel Wildcat Lake graphics
- eDP-1 2560x1600 @ scale 2
- 1password 8.12.36-2 (Omarchy repo), running under Wayland via uwsm
omarchy display text size→text size: 11 px,gtk text-scaling-factor: 0.9091
View raw text
## Description 1Password windows render their content at the GTK `text-scaling-factor` instead of the monitor scale when it is started from its own "Start at login" autostart entry, because that entry does not carry the `--force-device-scale-factor=1` pin that Omarchy applies everywhere else. With `omarchy display text size 11` (which is the **stock default on Dell XPS 13** via `install/user/hardware/dell/xps13-text-scaling.sh`), the GTK factor becomes `0.9091`. 1Password, being Electron, derives its device scale factor from that and draws its content at 0.909× while the Wayland surface keeps its full logical size. The result is a dialog that only fills ~90% of its window, with whatever is behind it visible in the gap (screenshot attached: the SSH-agent authorization dialog with a foot terminal showing through the right/bottom edge). Knock-on effect: the SSH authorization dialog is where you type the account password when 1Password is locked. In my case the mis-rendered prompt led to failed unlock attempts, the SSH authorization request timed out, and `ssh`/`git` failed with `agent refused operation`. ## Root cause Omarchy already pins the scale in two places: - `/usr/share/applications/1password.desktop` (Omarchy package `1password 8.12.36-2`): `Exec=/opt/1Password/1password --force-device-scale-factor=1 %U` - `bin/omarchy-launch-1password`: `exec setsid uwsm-app -- 1password --force-device-scale-factor=1` But when "Start 1Password at login" is enabled in 1Password's settings, 1Password writes its own `~/.config/autostart/com.onepassword.OnePassword.desktop` with: ``` Exec=/opt/1Password/1password --silent ``` That is the instance that runs for the whole session, and it has no scale pin, so neither of Omarchy's fixes apply. `omarchy-install-service-1password` doesn't touch the autostart entry either. ## Steps to reproduce 1. Install 1Password (`omarchy install service 1password`) and enable *Settings → General → Start 1Password at login* (or be on an XPS 13, where text size 11 is the default). 2. `omarchy display text size 11` 3. Log out and back in so 1Password starts from the autostart entry. 4. Open any 1Password window (e.g. trigger an SSH key authorization, or SUPER+SHIFT+/ — the main window is affected too as long as the `--silent` instance is the one that owns the windows). Expected: the window content fills the window, as it does when launched via `omarchy-launch-1password`. Actual: content is drawn at ~0.91× in the top-left of the window with a transparent gap on the right/bottom. Verified: `pgrep -a 1password` showed `/opt/1Password/1password --silent` (no flag). Killing it and relaunching with `--force-device-scale-factor=1 --silent` fixes the rendering immediately. ## Proposed fix Patch the autostart entry whenever Omarchy touches 1Password, and once for existing installs via a migration. Something like: ```bash # bin/omarchy-install-service-1password (after omarchy-pkg-add) and a new migration autostart="$HOME/.config/autostart/com.onepassword.OnePassword.desktop" if [[ -f $autostart ]] && ! grep -q -- '--force-device-scale-factor' "$autostart"; then sed -i -E 's|^(Exec=/opt/1Password/1password)|\1 --force-device-scale-factor=1|' "$autostart" fi ``` Caveat for the fix: 1Password rewrites this file when the "Start at login" toggle is flipped, so the pin can be lost again. A more robust alternative would be for Omarchy to ship its own autostart entry (e.g. `~/.config/autostart/1password.desktop` pointing at `omarchy-launch-1password --silent`) and tell users to leave 1Password's own toggle off — but that is a bigger change; the sed patch above covers the common case. Workaround for users hitting this now: ```bash sed -i 's|^Exec=/opt/1Password/1password --silent$|Exec=/opt/1Password/1password --force-device-scale-factor=1 --silent|' \ ~/.config/autostart/com.onepassword.OnePassword.desktop pkill -x 1password; setsid uwsm-app -- /opt/1Password/1password --force-device-scale-factor=1 --silent ``` ## System - Omarchy 4.0.4-1, kernel 7.2.5-3-omarchy - Dell XPS 13, Intel Core 5 320, Intel Wildcat Lake graphics - eDP-1 2560x1600 @ scale 2 - 1password 8.12.36-2 (Omarchy repo), running under Wayland via uwsm - `omarchy display text size` → `text size: 11 px`, `gtk text-scaling-factor: 0.9091`
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 14:42 UTC