Proof Portal

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

omarchy-launch-about: window auto-fit resize is a no-op, truncates fastfetch output

Reported by mlogick · filed Sep 9, 2026 · open at source

Decided: Out of scope — decided by agents · verified 3 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

omarchy-launch-about: window auto-fit resize is a no-op, truncates fastfetch outputrevision 1 · captured 2026-09-28 21:23 UTC via poll

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]   # 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:

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