Proof Portal

Sign in
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-83GitHub issuePublicDecided· Out of scope

Migration 1790042972 fails on every update when the running shell predates it ("Something went wrong during the update!")

Reported by kurtlieber · filed Sep 26, 2026 · open at source

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

Migration 1790042972 fails on every update when the running shell predates it ("Something went wrong during the update!")revision 1 · captured 2026-09-28 21:23 UTC via poll

What happened

Upgrading stable → edge (4.0.4 → 4.0.0.r2304.g7b336b1-1) left omarchy-update reporting failure:

omarchy-bar: could not put omacom.elsewhen on the bar: omarchy-shell is not responding

Something went wrong during the update!

The migration writes no marker, so it re-runs and re-fails on every subsequent omarchy update until the shell happens to answer within the 2s default IPC timeout. Observed 4× across two update runs.

Expected

The migration documents the intent itself (migrations/1790042972.sh, lines 20–21):

Best-effort, like the put below: an update whose shell cannot be asked still finishes, and restarts the shell once the migrations are through.

The put should be best-effort: package installed, symlink fixed, marker written; the bar placement retried on a later update/login.

Actual

Two contributing defects:

  1. omarchy-bar ask_to_put retries only "not ready" / "is not running"; a transient timeout ("not responding") is fatal on the first attempt. Identical putBarWidget calls were observed flapping ok → fail → ok within minutes on the same machine, so the timeout window is genuinely racy.
  2. The best-effort intent is not enforced at the migration: omarchy-bar put ... exits 1, bash -euo pipefail kills the script, omarchy-migrate writes no marker, and omarchy-update reports global failure. A || true (plus a best-effort notification to retry later) would match the documented intent.

Repro

Any update where the running shell does not answer within OMARCHY_SHELL_IPC_TIMEOUT (default 2s) while migration 1790042972 is pending — most reliably during the stable → edge channel switch, where the running shell predates the new IPC surface. omarchy-migrate then fails the same way on every retry.

System

  • Omarchy 4.0.0.r2304.g7b336b1-1 (edge), Hyprland 0.56.2-3
  • quickshell 0.3.1-1, Arch Linux x86_64
View raw text
### What happened

Upgrading stable → edge (4.0.4 → 4.0.0.r2304.g7b336b1-1) left `omarchy-update` reporting failure:

```
omarchy-bar: could not put omacom.elsewhen on the bar: omarchy-shell is not responding

Something went wrong during the update!
```

The migration writes no marker, so it re-runs and re-fails on every subsequent `omarchy update` until the shell happens to answer within the 2s default IPC timeout. Observed 4× across two update runs.

### Expected

The migration documents the intent itself (`migrations/1790042972.sh`, lines 20–21):

> Best-effort, like the put below: an update whose shell cannot be asked still finishes, and restarts the shell once the migrations are through.

The put should be best-effort: package installed, symlink fixed, marker written; the bar placement retried on a later update/login.

### Actual

Two contributing defects:

1. `omarchy-bar ask_to_put` retries only "not ready" / "is not running"; a transient timeout ("not responding") is fatal on the first attempt. Identical `putBarWidget` calls were observed flapping ok → fail → ok within minutes on the same machine, so the timeout window is genuinely racy.
2. The best-effort intent is not enforced at the migration: `omarchy-bar put ...` exits 1, `bash -euo pipefail` kills the script, `omarchy-migrate` writes no marker, and `omarchy-update` reports global failure. A `|| true` (plus a best-effort notification to retry later) would match the documented intent.

### Repro

Any update where the running shell does not answer within `OMARCHY_SHELL_IPC_TIMEOUT` (default 2s) while migration 1790042972 is pending — most reliably during the stable → edge channel switch, where the running shell predates the new IPC surface. `omarchy-migrate` then fails the same way on every retry.

### System

- Omarchy 4.0.0.r2304.g7b336b1-1 (edge), Hyprland 0.56.2-3
- quickshell 0.3.1-1, Arch Linux x86_64

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 19:49 UTC