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-restart: confirm_reboot has no unattended guard, still hangs under -y
Reported by PixelatedContinuum · filed Aug 30, 2026Closed upstream on 2026-08-30 by its own reporter PixelatedContinuum, as a duplicate of #8986 (R-1252). GitHub close reason: duplicate.
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?
- Not yet mapped to any requirement or component.
- 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?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
Follow-up to #8780 — flagged separately per the note in that issue's timeline, since both open fixes (#8824, #8894) say "Fixes #8780" and neither touches this path.
What happens
omarchy update -y can still block on interactive input, this time in omarchy-update-restart rather than the orphan-package step #8780 covers. confirm_reboot() in bin/omarchy-update-restart has no unattended guard at all — not even the (currently ineffective) TTY check omarchy-update-orphan-pkgs has:
confirm_reboot() {
gum confirm "$1" && { omarchy-system-reboot; exit 0; }
}It's called unconditionally from three sites in the same file, any one of which is a normal outcome of an update:
- the running kernel has no matching installed module directory (kernel was updated)
~/.local/state/omarchy/reboot-requiredexists- Hyprland's own binary was replaced while running (
readlinkon its/proc/.../exeshows(deleted))
bin/omarchy-update runs omarchy-update-restart unconditionally at the end of every update, -y included, so this isn't an edge case — any update that touches the kernel or Hyprland hits it.
Why this isn't just a repeat of #8780
It's the same failure mode with one less layer. omarchy-update-orphan-pkgs at least has [[ ! -t 0 || ! -t 1 ]], which is exactly the check #8780 found doesn't fire under -y — omarchy-update re-execs the whole run through script -qefc for logging, and script(1) allocates a pty on both descriptors, so -t 0/-t 1 read true even with nobody there to answer. confirm_reboot never had that check to begin with.
What's already there for the fix
omarchy-update already exports OMARCHY_UPDATE_UNATTENDED=1 on -y, before any pipeline step runs — including omarchy-update-restart. It's already inherited here with no plumbing needed; this looks like a local, single-function fix in bin/omarchy-update-restart, e.g.:
confirm_reboot() {
if [[ ${OMARCHY_UPDATE_UNATTENDED:-} == 1 ]]; then
echo "$1 Re-run omarchy update in a terminal to confirm."
return
fi
gum confirm "$1" && { omarchy-system-reboot; exit 0; }
}Report-and-continue rather than report-and-exit, since confirm_reboot is called from three separate sites and the shell-restart step still needs to run afterward — and continuing rather than auto-confirming keeps the same default #8824/#8894 chose for orphaned packages: an unattended run shouldn't take an action as disruptive as a reboot on its own say-so.
Expected
omarchy update -y completes without blocking on any of the three reboot/restart prompts.
System
- Omarchy 4.0.1-1
View raw text
Follow-up to #8780 — flagged separately per the note in that issue's timeline, since both open fixes (#8824, #8894) say "Fixes #8780" and neither touches this path.
## What happens
`omarchy update -y` can still block on interactive input, this time in `omarchy-update-restart` rather than the orphan-package step #8780 covers. `confirm_reboot()` in `bin/omarchy-update-restart` has no unattended guard at all — not even the (currently ineffective) TTY check `omarchy-update-orphan-pkgs` has:
```bash
confirm_reboot() {
gum confirm "$1" && { omarchy-system-reboot; exit 0; }
}
```
It's called unconditionally from three sites in the same file, any one of which is a normal outcome of an update:
- the running kernel has no matching installed module directory (kernel was updated)
- `~/.local/state/omarchy/reboot-required` exists
- Hyprland's own binary was replaced while running (`readlink` on its `/proc/.../exe` shows `(deleted)`)
`bin/omarchy-update` runs `omarchy-update-restart` unconditionally at the end of every update, `-y` included, so this isn't an edge case — any update that touches the kernel or Hyprland hits it.
## Why this isn't just a repeat of #8780
It's the same failure mode with one less layer. `omarchy-update-orphan-pkgs` at least has `[[ ! -t 0 || ! -t 1 ]]`, which is exactly the check #8780 found doesn't fire under `-y` — `omarchy-update` re-execs the whole run through `script -qefc` for logging, and `script(1)` allocates a pty on both descriptors, so `-t 0`/`-t 1` read true even with nobody there to answer. `confirm_reboot` never had that check to begin with.
## What's already there for the fix
`omarchy-update` already exports `OMARCHY_UPDATE_UNATTENDED=1` on `-y`, before any pipeline step runs — including `omarchy-update-restart`. It's already inherited here with no plumbing needed; this looks like a local, single-function fix in `bin/omarchy-update-restart`, e.g.:
```bash
confirm_reboot() {
if [[ ${OMARCHY_UPDATE_UNATTENDED:-} == 1 ]]; then
echo "$1 Re-run omarchy update in a terminal to confirm."
return
fi
gum confirm "$1" && { omarchy-system-reboot; exit 0; }
}
```
Report-and-continue rather than report-and-exit, since `confirm_reboot` is called from three separate sites and the shell-restart step still needs to run afterward — and continuing rather than auto-confirming keeps the same default #8824/#8894 chose for orphaned packages: an unattended run shouldn't take an action as disruptive as a reboot on its own say-so.
## Expected
`omarchy update -y` completes without blocking on any of the three reboot/restart prompts.
## System
- Omarchy 4.0.1-1
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.
No decision has been recorded yet.