## Summary

`omarchy display text size` (and the Display panel's Text size slider) sets GNOME's `text-scaling-factor`. Chromium/Electron apps **multiply that factor into their device scale factor**, which shrinks the usable layout area of any fixed-size window by the same factor. 1Password's SSH authorization prompt is such a window — ~402x371 logical px with min size = max size — so at text size 16 (factor 1.3636) about 26% of the dialog's content, including the authorize button, is pushed off-window.

This is the root cause behind #2016 ("1Password authorization window cut off"), which was closed without a fix and attributed to a 1Password regression. It also explains the confusing per-machine variance reported there (same monitor scale, different outcome): the trigger is the *text* scale, not the monitor scale.

## Reproduce

1. `omarchy display text size 16` (any value above 12 works; bigger is worse)
2. Restart 1Password so it picks the factor up, enable its SSH agent
3. Trigger any SSH signature, e.g. without touching the network:
   ```bash
   ssh-add -L > /tmp/k.pub
   SSH_AUTH_SOCK=~/.1password/agent.sock ssh-keygen -Y sign -f /tmp/k.pub -U -n test /etc/hostname
   ```
4. The authorization dialog appears with its checkbox/buttons clipped.

The dialog cannot be rescued compositor-side: it reports min size = max size, so `size` window rules and `hl.dsp.window.resize(...)` are silently ignored — which is why the window-rule attempts in #2016 only ever affected the main window.

## Root cause, measured

Chromium computes its device scale on Wayland as `monitor scale x text-scaling-factor`. Verified with a scratch Chromium and CDP (`Runtime.evaluate` on `window.devicePixelRatio` via `--remote-debugging-port`), on a 2x monitor with text size 16 (factor 1.3636):

| Launch | devicePixelRatio |
|---|---|
| baseline | **2.71875** (= 2 x 1.36) |
| `GDK_DPI_SCALE=0.733` | 2.71875 — no effect on Chromium |
| `--force-device-scale-factor=2` | 4.0 — multiplies, worse |
| `GSETTINGS_BACKEND=memory` | **2.0 — fixed** |

The window frame stays at its fixed logical size while the app lays out at the inflated DPR, so the dialog's 402 logical px become `402 x 2 / 2.72 ≈ 295` CSS px of layout — content designed for 402 gets clipped. The same math applies to the main window (the 875x600 `floating-window` tag default becomes ~643 effective px — the "1Password window too small" complaints).

## Fix

Launch 1Password with `GSETTINGS_BACKEND=memory`: in-process gsettings reads come back as defaults, so it renders at the plain monitor scale and every fixed-size dialog gets its full designed layout (the SSH prompt even sizes itself taller, 402x426 here, everything visible). Dark/light detection is portal-based and keeps working.

One gotcha makes placement non-obvious: **1Password rewrites `~/.config/autostart/1password.desktop` on startup**, so the env cannot live in the autostart desktop file. Since Omarchy runs XDG autostart entries as `app-<name>@autostart.service` units, a systemd user drop-in survives:

```ini
# /etc/systemd/user/[email protected]/text-scaling.conf
[Service]
Environment=GSETTINGS_BACKEND=memory
```

PR incoming that applies this on every launch path (launcher, installer, desktop override, packaged autostart drop-in, migration). Bitwarden and other Electron apps with fixed-size dialogs have the same exposure; the trade-off (the app renders at standard size instead of following the text scale; in-app Ctrl+= compensates) is documented in the drop-in.

The proper fix belongs to 1Password (size fixed dialogs in CSS px, or make them resizable) — worth reporting upstream too, but Omarchy controls the trigger, so a guard here helps users today.

## Environment

- Omarchy 4.0.1-1, Hyprland 0.56.2
- 1Password 8.12.32 (conceptually matches the 8.11.x reports in #2016)
- Monitor 3840x2160 @ scale 2; `text-scaling-factor` 1.3636 (set by `omarchy display text size 16`)

(No screenshot: Omarchy correctly tags 1Password `no_screen_share`, captures come out black.)