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 update -y` can block at the post-update reboot prompt
Reported by maxcroy1 · filed Aug 29, 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
System details
Current quattro checkout at 56fbaf4689e3eb6867c0b7f375ae49964f183774. This is hardware-independent shell control flow and was validated with an isolated, fully stubbed harness.
What is wrong?
omarchy update -y exports OMARCHY_UPDATE_UNATTENDED=1, documented as a promise not to ask anything, and eventually calls omarchy-update-restart.
confirm_reboot currently calls gum confirm without checking OMARCHY_UPDATE_UNATTENDED or whether its input/output streams are usable terminals:
confirm_reboot() {
gum confirm "$1" && { omarchy-system-reboot; exit 0; }
}When a kernel update, reboot-required marker, or replaced Hyprland executable reaches this function, an unattended update can stop at the reboot question. The update runs inside script(1), which allocates a pseudo-terminal even when the outer caller has closed stdin, so a TTY-only check would not preserve the -y contract.
This was reproduced four out of four times by running the real helper under the same pseudo-TTY shape with OMARCHY_UPDATE_UNATTENDED=1 and closed outer stdin. A fake HOME and isolated PATH stubbed uname, pacman, gum, pgrep, omarchy-system-reboot, omarchy-state, and restart commands. The prompt stub recorded:
gum stdin=yes stdout=yes unattended=1 args=confirm Linux kernel has been updated. Reboot?The real gum prompt and all package, state, restart, and reboot operations were intentionally not executed.
Expected behavior: unattended and headless restart checks should report that a reboot is needed without prompting or rebooting. An interactive update should continue to offer the reboot.
This is the restart-path follow-up called out in #8780. The orphan-prompt fixes in #8824 and #8894 do not change omarchy-update-restart, and merging either can close #8780 while this path remains.
A guard should honor OMARCHY_UPDATE_UNATTENDED as well as the descriptors gum confirm needs, following the existing unattended-update pattern in omarchy-update-system-pkgs-when-conflicted.
View raw text
### System details
Current `quattro` checkout at `56fbaf4689e3eb6867c0b7f375ae49964f183774`. This is hardware-independent shell control flow and was validated with an isolated, fully stubbed harness.
### What is wrong?
`omarchy update -y` exports `OMARCHY_UPDATE_UNATTENDED=1`, documented as a promise not to ask anything, and eventually calls `omarchy-update-restart`.
`confirm_reboot` currently calls `gum confirm` without checking `OMARCHY_UPDATE_UNATTENDED` or whether its input/output streams are usable terminals:
```bash
confirm_reboot() {
gum confirm "$1" && { omarchy-system-reboot; exit 0; }
}
```
When a kernel update, `reboot-required` marker, or replaced Hyprland executable reaches this function, an unattended update can stop at the reboot question. The update runs inside `script(1)`, which allocates a pseudo-terminal even when the outer caller has closed stdin, so a TTY-only check would not preserve the `-y` contract.
This was reproduced four out of four times by running the real helper under the same pseudo-TTY shape with `OMARCHY_UPDATE_UNATTENDED=1` and closed outer stdin. A fake `HOME` and isolated `PATH` stubbed `uname`, `pacman`, `gum`, `pgrep`, `omarchy-system-reboot`, `omarchy-state`, and restart commands. The prompt stub recorded:
```text
gum stdin=yes stdout=yes unattended=1 args=confirm Linux kernel has been updated. Reboot?
```
The real `gum` prompt and all package, state, restart, and reboot operations were intentionally not executed.
Expected behavior: unattended and headless restart checks should report that a reboot is needed without prompting or rebooting. An interactive update should continue to offer the reboot.
This is the restart-path follow-up called out in #8780. The orphan-prompt fixes in #8824 and #8894 do not change `omarchy-update-restart`, and merging either can close #8780 while this path remains.
A guard should honor `OMARCHY_UPDATE_UNATTENDED` as well as the descriptors `gum confirm` needs, following the existing unattended-update pattern in `omarchy-update-system-pkgs-when-conflicted`.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
- Fixed bypr/9511· confirmed
- Related PRpr/9472· confirmed
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 10:00 UTC