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.
Bar disappears after omarchy update: restart-shell launches before the old shell exits (5s kill timeout)
Reported by ferpa · filed Oct 2, 2026Closed upstream on 2026-10-04 by the bot omarchybot; the closing comment says it was fixed by PR #11015. GitHub close reason: completed.
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
System details
- Omarchy 4.0.4-1 (updated from the previous version in this same run)
- quickshell 0.3.1-1, hyprland 0.56.2-2
- AMD Ryzen 9 5900HX, NVIDIA RTX 3060 Mobile + AMD Radeon Vega (Cezanne)
What's wrong
After omarchy update, the bar is gone: no quickshell process is left running. omarchy restart shell brings it back.
omarchy-update-restart calls omarchy-restart-shell, and the old shell exits on the IPC kill. Exactly 5 seconds later the replacement starts, finds the old instance still registered, and quits:
16:05:09 pacman -Syu (update) finishes
16:05:17 omarchy-shell[3518099]: INFO: Exiting due to IPC request.
16:05:22 omarchy-shell[2760885]: An instance of this configuration is already running.After that, no shell is running.
Likely cause
In omarchy-restart-shell:
while timeout 5 quickshell kill -p "$CONFIG_DIR" --any-display >/dev/null 2>&1; do :; done
hyprctl dispatch 'hl.dsp.exec_cmd("omarchy-launch-shell")' >/dev/nullThe comment says each kill "only returns once it has fully exited, so the no-duplicate launch below can't race a dying shell". But when the old shell takes more than 5 s to exit, timeout stops the waiting quickshell kill, the loop sees non-zero, and the launch goes ahead while the old instance is still alive. The 5 s gap in the log matches the timeout exactly.
The new quickshell -n then refuses to start as a duplicate. omarchy-launch-shell treats that exit as a deliberate clean stop ((( status == 0 )) && exit 0), so the supervisor doesn't relaunch. The result is no bar until a manual restart.
Two possible fixes: after the kill loop, wait for the old instance to actually disappear (e.g. poll quickshell list -p "$CONFIG_DIR" with a longer deadline) before launching. Alternatively, have the restart retry the launch when the ping loop fails.
Steps to reproduce
- Run
omarchy updatewith an Omarchy package upgrade pending, so the update ends in "Restarting shell". - If the old shell takes more than 5 s to exit, the bar doesn't come back.
It's intermittent and depends on how long the old shell takes to exit. It has happened to me more than once after updates.
View raw text
### System details
- Omarchy 4.0.4-1 (updated from the previous version in this same run)
- quickshell 0.3.1-1, hyprland 0.56.2-2
- AMD Ryzen 9 5900HX, NVIDIA RTX 3060 Mobile + AMD Radeon Vega (Cezanne)
### What's wrong
After `omarchy update`, the bar is gone: no quickshell process is left running. `omarchy restart shell` brings it back.
`omarchy-update-restart` calls `omarchy-restart-shell`, and the old shell exits on the IPC kill. Exactly 5 seconds later the replacement starts, finds the old instance still registered, and quits:
```
16:05:09 pacman -Syu (update) finishes
16:05:17 omarchy-shell[3518099]: INFO: Exiting due to IPC request.
16:05:22 omarchy-shell[2760885]: An instance of this configuration is already running.
```
After that, no shell is running.
### Likely cause
In `omarchy-restart-shell`:
```bash
while timeout 5 quickshell kill -p "$CONFIG_DIR" --any-display >/dev/null 2>&1; do :; done
hyprctl dispatch 'hl.dsp.exec_cmd("omarchy-launch-shell")' >/dev/null
```
The comment says each kill "only returns once it has fully exited, so the no-duplicate launch below can't race a dying shell". But when the old shell takes more than 5 s to exit, `timeout` stops the waiting `quickshell kill`, the loop sees non-zero, and the launch goes ahead while the old instance is still alive. The 5 s gap in the log matches the timeout exactly.
The new `quickshell -n` then refuses to start as a duplicate. `omarchy-launch-shell` treats that exit as a deliberate clean stop (`(( status == 0 )) && exit 0`), so the supervisor doesn't relaunch. The result is no bar until a manual restart.
Two possible fixes: after the kill loop, wait for the old instance to actually disappear (e.g. poll `quickshell list -p "$CONFIG_DIR"` with a longer deadline) before launching. Alternatively, have the restart retry the launch when the ping loop fails.
### Steps to reproduce
1. Run `omarchy update` with an Omarchy package upgrade pending, so the update ends in "Restarting shell".
2. If the old shell takes more than 5 s to exit, the bar doesn't come back.
It's intermittent and depends on how long the old shell takes to exit. It has happened to me more than once after updates.
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.