Proof Portal

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-1783GitHub issuePublicDecided· Out of scope

Migration 1781587663 aborts the whole migration queue when omarchy-nvim is not installed

Reported by omarchybot · filed Aug 16, 2026 · open at source

Decided: Out of scope — decided by agents · verified 4 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 1781587663 aborts the whole migration queue when omarchy-nvim is not installedrevision 1 · captured 2026-09-28 21:29 UTC via poll

System details: Omarchy quattro @ 7488eade (post-4.0.0), QEMU/KVM VM. Found by an automated QA pass; mechanism reproduced on a disposable worker VM with the source path absent.

A user who has ~/.config/nvim but not the omarchy-nvim package hard-fails migration 1781587663, which aborts the whole migration queue and the rest of omarchy update behind it.

provider_source="/usr/share/omarchy-nvim/config/lua/config/remote_clipboard.lua"

if [[ -d $nvim_config_dir ]]; then
  mkdir -p "$(dirname "$nvim_provider")"
  install -m 0644 "$provider_source" "$nvim_provider"

The guard tests the user's nvim directory, but the file comes from a separate, removable package (install/omarchy-base.packages:98; pacman -Qi omarchy-nvim confirms it is its own package). Anyone running their own Neovim config with omarchy-nvim dropped, on a legacy git-checkout install, or midway through a failed omarchy-upgrade-to-quattro, gets:

Enable secure remote Neovim clipboard support
install: cannot stat '/usr/share/omarchy-nvim/config/lua/config/remote_clipboard.lua': No such file or directory
exit=1

There is no [[ -f $provider_source ]] || exit 0. Contrast 1784809451.sh:16, which was amended in a6a13cf3 to add exactly that guard after the same class of bug.

Two notes for whoever picks this up. First, #6143 reported the packaging side of this (the file missing from the package) and said the failure was absorbed — that is no longer true; under bash -euo pipefail it is fatal. Second, the blast radius is set by bin/omarchy-migrate:93 running each migration bare under the runner's own set -euo pipefail, so one failing migration ends the queue and skips every remaining step of omarchy-update — that part is #7078, and this is one concrete way in.


Correction, after an independent review of this report:

Narrower than filed. This bites when the migration is still pending, ~/.config/nvim exists, and the provider file is absent. Fresh installs mark all shipped migrations complete, and bin/omarchy-upgrade-to-quattro:722 installs omarchy-nvim before migrations and absorbs migration failure at :1189 -- so the "midway through a failed upgrade" population named above is wrong.

View raw text
**System details:** Omarchy `quattro` @ 7488eade (post-4.0.0), QEMU/KVM VM. Found by an automated QA pass; mechanism reproduced on a disposable worker VM with the source path absent.

A user who has `~/.config/nvim` but not the `omarchy-nvim` package hard-fails migration `1781587663`, which aborts the whole migration queue and the rest of `omarchy update` behind it.

```bash
provider_source="/usr/share/omarchy-nvim/config/lua/config/remote_clipboard.lua"

if [[ -d $nvim_config_dir ]]; then
  mkdir -p "$(dirname "$nvim_provider")"
  install -m 0644 "$provider_source" "$nvim_provider"
```

The guard tests the *user's* nvim directory, but the file comes from a separate, removable package (`install/omarchy-base.packages:98`; `pacman -Qi omarchy-nvim` confirms it is its own package). Anyone running their own Neovim config with `omarchy-nvim` dropped, on a legacy git-checkout install, or midway through a failed `omarchy-upgrade-to-quattro`, gets:

```
Enable secure remote Neovim clipboard support
install: cannot stat '/usr/share/omarchy-nvim/config/lua/config/remote_clipboard.lua': No such file or directory
exit=1
```

There is no `[[ -f $provider_source ]] || exit 0`. Contrast `1784809451.sh:16`, which was amended in `a6a13cf3` to add exactly that guard after the same class of bug.

Two notes for whoever picks this up. First, #6143 reported the packaging side of this (the file missing from the package) and said the failure was absorbed — that is no longer true; under `bash -euo pipefail` it is fatal. Second, the blast radius is set by `bin/omarchy-migrate:93` running each migration bare under the runner's own `set -euo pipefail`, so one failing migration ends the queue and skips every remaining step of `omarchy-update` — that part is #7078, and this is one concrete way in.

---

**Correction, after an independent review of this report:**

Narrower than filed. This bites when the migration is still pending, `~/.config/nvim` exists, and the provider file is absent. Fresh installs mark all shipped migrations complete, and `bin/omarchy-upgrade-to-quattro:722` installs `omarchy-nvim` before migrations and absorbs migration failure at `:1189` -- so the "midway through a failed upgrade" population named above is wrong.

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 04:22 UTC