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.
omarchy-launch-about: window auto-fit resize is a no-op, truncates fastfetch output
Reported by mlogick · filed Sep 9, 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
What happened
omarchy launch about (SUPER+ALT+U by default) opens a floating terminal that's too small on a fresh install, and the fastfetch output stays truncated: the logo is cut off partway through, several modules never appear, and the rest of the window is blank. It never self-corrects.
Expected
The floating "about" window should size itself to fit the logo + modules on first launch — that's exactly what omarchy-launch-about's fit_window() is designed to do.
Root cause
fit_window() (in omarchy-launch-about) grows the window toward a measured target grid by calling:
hl.dsp.window.resize({ window = "address:$address", x = $target_w, y = $target_h })via the hypr_dispatch helper. On this build, that dispatch reports success but never actually changes the window's size. Reproduced directly, outside of the about script entirely:
$ hyprctl dispatch "hl.dsp.window.resize({ window = \"address:$ADDR\", x = 1100, y = 700 })"
ok
$ hyprctl clients -j | jq '.[] | select(.address=="'$ADDR'") | .size'
[700,500] # unchangedSince there's no cached ~/.local/state/omarchy/windows/about.fit on a fresh install, presize_window() has nothing to apply before launch either, so the window opens at foot's bare default (700x500px / 80x24 grid). fit_window()'s 2-nudge budget is then exhausted without ever growing the window, so no fit gets recorded and the truncation repeats on every launch.
Steps to reproduce
- Fresh Omarchy install (channel
stable), no prior~/.local/state/omarchy/windows/about.fit. - Run
omarchy launch about(or the default SUPER+ALT+U bind). - The logo/output renders truncated in a small window. Screenshot attached.
Workaround
A static window rule (float + center + fixed size) for org.omarchy.about in ~/.config/hypr/hyprland.lua sidesteps the broken runtime resize entirely, since it sizes the window correctly before foot/fastfetch ever paints:
o.window("org.omarchy.about", {
float = true,
center = true,
size = { 1200, 800 },
})System
- Omarchy 4.0.3-1, channel: stable
- Hyprland 0.56.2 (v0.56.2, commit efb50993)
- Kernel 7.2.3-arch1-3 (Arch)
- CPU: Intel Core i5-8350U, GPU: Intel UHD Graphics 620 (ThinkPad T480)
- Terminal: foot (default)
Note: omarchy debug --no-sudo --print returned "Unknown Omarchy command" on this install, so I've listed system details manually above instead.
View raw text
## What happened
`omarchy launch about` (SUPER+ALT+U by default) opens a floating terminal that's too small on a fresh install, and the fastfetch output stays truncated: the logo is cut off partway through, several modules never appear, and the rest of the window is blank. It never self-corrects.
## Expected
The floating "about" window should size itself to fit the logo + modules on first launch — that's exactly what `omarchy-launch-about`'s `fit_window()` is designed to do.
## Root cause
`fit_window()` (in `omarchy-launch-about`) grows the window toward a measured target grid by calling:
```bash
hl.dsp.window.resize({ window = "address:$address", x = $target_w, y = $target_h })
```
via the `hypr_dispatch` helper. On this build, that dispatch reports success but never actually changes the window's size. Reproduced directly, outside of the about script entirely:
```
$ hyprctl dispatch "hl.dsp.window.resize({ window = \"address:$ADDR\", x = 1100, y = 700 })"
ok
$ hyprctl clients -j | jq '.[] | select(.address=="'$ADDR'") | .size'
[700,500] # unchanged
```
Since there's no cached `~/.local/state/omarchy/windows/about.fit` on a fresh install, `presize_window()` has nothing to apply before launch either, so the window opens at foot's bare default (700x500px / 80x24 grid). `fit_window()`'s 2-nudge budget is then exhausted without ever growing the window, so no fit gets recorded and the truncation repeats on every launch.
## Steps to reproduce
1. Fresh Omarchy install (channel `stable`), no prior `~/.local/state/omarchy/windows/about.fit`.
2. Run `omarchy launch about` (or the default SUPER+ALT+U bind).
3. The logo/output renders truncated in a small window. Screenshot attached.
## Workaround
A static window rule (float + center + fixed size) for `org.omarchy.about` in `~/.config/hypr/hyprland.lua` sidesteps the broken runtime resize entirely, since it sizes the window correctly before foot/fastfetch ever paints:
```lua
o.window("org.omarchy.about", {
float = true,
center = true,
size = { 1200, 800 },
})
```
## System
- Omarchy 4.0.3-1, channel: stable
- Hyprland 0.56.2 (v0.56.2, commit efb50993)
- Kernel 7.2.3-arch1-3 (Arch)
- CPU: Intel Core i5-8350U, GPU: Intel UHD Graphics 620 (ThinkPad T480)
- Terminal: foot (default)
Note: `omarchy debug --no-sudo --print` returned "Unknown Omarchy command" on this install, so I've listed system details manually above instead.
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 11:22 UTC