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.
Pointer stays invisible after login on edge (startup-cursor restore doesn't run)
Reported by Haze-dev1 · filed Oct 11, 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
Since switching to the edge channel, the mouse pointer is invisible after login.
Expected: the pointer appears once the startup intro finishes (a few seconds).
Actual: on one login it never came back at all; on another it took ~15-20s.
default/hypr/startup-cursor.lua swaps in the blank omarchy-startup Xcursor
theme at startup. The quick restore (BackgroundIntro.qml callingomarchy_startup_cursor_restore() via hyprctl eval) doesn't seem to take effect,
so the pointer only returns via the 15s fallback timer, or not at all.
On the failed login, cursor:invisible was already false but the pointer
was still blank: the real theme had not been reloaded. Runninghyprctl setcursor default 24 immediately brought it back.
The Hyprland log had no trace of the restore's hyprctl setcursor running.
Steps to reproduce
- Edge channel, single external HDMI monitor (internal eDP-1 disabled)
- Log in
- Pointer is invisible; it either appears after ~15s or never
Workaround
In ~/.config/hypr/autostart.lua:
o.launch_on_start("sh -c 'sleep 20; hyprctl setcursor \"${XCURSOR_THEME:-default}\" \"${XCURSOR_SIZE:-24}\"'")
System
- Omarchy: omarchy-dev 4.0.0.r6871.g04b374a-1 (edge)
- Hyprland: 0.56.2 (efb5099)
- Kernel: 7.2.8-5-omarchy-bore
- CPU: Intel Core Ultra 7 155H
- GPU: Intel Arc Graphics (Meteor Lake-P)
- Display: HDMI-A-1 1920x1080@60 only, eDP-1 disabled
- XCURSOR_THEME=default, XCURSOR_SIZE=24, HYPRCURSOR_THEME unset
Diagnostics
Debug log available on request.
View raw text
## Description
Since switching to the edge channel, the mouse pointer is invisible after login.
Expected: the pointer appears once the startup intro finishes (a few seconds).
Actual: on one login it never came back at all; on another it took ~15-20s.
`default/hypr/startup-cursor.lua` swaps in the blank `omarchy-startup` Xcursor
theme at startup. The quick restore (`BackgroundIntro.qml` calling
`omarchy_startup_cursor_restore()` via `hyprctl eval`) doesn't seem to take effect,
so the pointer only returns via the 15s fallback timer, or not at all.
On the failed login, `cursor:invisible` was already `false` but the pointer
was still blank: the real theme had not been reloaded. Running
`hyprctl setcursor default 24` immediately brought it back.
The Hyprland log had no trace of the restore's `hyprctl setcursor` running.
## Steps to reproduce
1. Edge channel, single external HDMI monitor (internal eDP-1 disabled)
2. Log in
3. Pointer is invisible; it either appears after ~15s or never
## Workaround
In `~/.config/hypr/autostart.lua`:
o.launch_on_start("sh -c 'sleep 20; hyprctl setcursor \"${XCURSOR_THEME:-default}\" \"${XCURSOR_SIZE:-24}\"'")
## System
- Omarchy: omarchy-dev 4.0.0.r6871.g04b374a-1 (edge)
- Hyprland: 0.56.2 (efb5099)
- Kernel: 7.2.8-5-omarchy-bore
- CPU: Intel Core Ultra 7 155H
- GPU: Intel Arc Graphics (Meteor Lake-P)
- Display: HDMI-A-1 1920x1080@60 only, eDP-1 disabled
- XCURSOR_THEME=default, XCURSOR_SIZE=24, HYPRCURSOR_THEME unset
## Diagnostics
Debug log available on request.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-11 05:57 UTC