### System details

ThinkPad X1 Carbon Gen 14 (21V7CTO1WW) · Intel Core Ultra X7 368H · Intel Arc B390 (Panther Lake) · kernel 7.1.8-arch1-3 · Omarchy 4.0.0-1 · Hyprland 0.56.2

Monitors: `eDP-1` 2880x1800@120, built-in, 244 DPI · `DP-1` 3440x1440@60, Dell U3425WE, 109 DPI

(Collected by hand — `omarchy debug` no longer exists in 4.0.0-1, and `omarchy commands --all` lists no replacement.)

### What's wrong?

`set_scale()` in `bin/omarchy-hyprland-monitor-scaling` applies a scale per monitor but persists it globally:

- `:89` — `hyprctl eval` applies the new scale to the **focused** output only (correct).
- `:94-97` — `sed -i` then rewrites `local omarchy_monitor_scale`, which the shipped catch-all `hl.monitor({ output = "", ..., scale = omarchy_monitor_scale })` applies to **every** output.

The consequence that I don't see tracked anywhere: the shipped value is `"auto"` (`config/hypr/monitors.lua`), i.e. per-monitor DPI-derived scaling. The **first** manual scale adjustment replaces that string with a single number, so a one-off nudge on one monitor silently and permanently converts per-monitor auto scaling into one fixed scale shared by all monitors. Nothing in the UI can put `"auto"` back — only editing the file, or `omarchy refresh config hypr/monitors.lua`, which discards the rest of the user's monitor config.

After that, every subsequent adjustment on either monitor re-binds both, so a laptop + external pair with different DPI cannot keep two different scales across a reload, redock or lid-open. The same `sed` also rewrites `omarchy_gdk_scale` to `int(scale + 0.5)` (`:86`, `:97`), so GTK scaling follows whichever monitor was touched last.

### Steps to reproduce

1. Stock 4.0.0-1 `~/.config/hypr/monitors.lua` (`local omarchy_monitor_scale = "auto"`), laptop plus an external monitor of clearly different DPI.
2. Focus the laptop, run `omarchy hyprland monitor scaling 1.6`.
3. `grep omarchy_monitor_scale ~/.config/hypr/monitors.lua` → now `1.6`. `"auto"` is gone for good.
4. Focus the external monitor, set the scale you want there. On the next `hyprctl reload`, redock or lid-open, **both** monitors take that value.

Expected: adjusting one monitor persists for that monitor and leaves the others — and `"auto"` — alone.

### Evidence

From `~/.local/state/omarchy/monitor-scaling.log` on this machine. The first entry is three minutes after the Lua migration generated `monitors.lua` from the stock template:

```
at=2026-08-13T14:25:47  requested=1.25  current=2     new=1.25  monitor=eDP-1
at=2026-08-13T14:25:50  requested=1.6   current=1.25  new=1.6   monitor=eDP-1
at=2026-08-13T15:19:55  requested=1     current=1.6   new=1     monitor=DP-1
```

`current=2` is what `"auto"` resolved to on the 244-DPI panel. Declining that once was enough to destroy `auto`; the 11 scale changes logged over the following four days are the resulting pendulum between the two monitors.

### Relation to existing reports

- **#6909** — @jesseburlamaque's comment describes this same `set_scale()` mechanism and proposes the same shape of fix. That issue is being tracked as the stock-config view of #7084 (the 2-second clamshell poll), so this defect currently has no issue of its own.
- **#7084 / #7146** — the parsing side (`desc:`-keyed and multiline rules). @mkelk notes in #6909 that the "no internal rule + `auto`" path still needs a separate behaviour change; #7146 does not touch `set_scale`.
- **#7301** — the wake path can't parse `"auto"` either and asserts a hardcoded `echo 2` (`bin/omarchy-hyprland-monitor-clamshell:137`).

All three share one root: the config format can express per-monitor scale, but scale *persistence* can only express a single global number.

### Suggested fix

Persist by adding or replacing a per-output rule for the focused monitor instead of mutating the global variable, and leave the catch-all at `"auto"`. That makes the `eval` and the persistence agree, and keeps a sane default for monitors the user has never configured. It would also relieve the fallback pressure in the clamshell path, since the internal panel gets a real numeric rule the moment its scale is adjusted.

### Workaround

Per-output rules are the known workaround. Worth adding: the catch-all can also be protected from the rewrite, so unknown monitors keep `auto`. The regex at `:100` matches only the exact shipped key order, so reordering the keys immunises the line:

```lua
hl.monitor({ output = "", scale = "auto", mode = "preferred", position = "auto" })
hl.monitor({ output = "eDP-1", mode = "preferred", position = "auto", scale = 1.6 })
hl.monitor({ output = "DP-1", mode = "preferred", position = "auto", scale = 1.25 })
```

Neither `sed` branch then matches — `local omarchy_monitor_scale` is gone, and the catch-all no longer matches the fixed key order — so scale changes from the menu stay live-only and the file remains the source of truth. Keep each rule on one line; the clamshell lookup requires that (#7084).