Proof Portal

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

mise stubs cannot be restored after ~/.local/bin is cleared, silently breaking the documented gh auto-install

Reported by amaurisd97 · filed Sep 29, 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

mise stubs cannot be restored after ~/.local/bin is cleared, silently breaking the documented gh auto-installrevision 1 · captured 2026-09-29 04:24 UTC via poll

Problem

install/user/mise.sh creates 15 lazy-install stubs in ~/.local/bin/ via omarchy-mise-install. Each wrapper runs mise use -g <pkg> on first execution, so the tool installs itself.

manual/18-development-tools.md documents this for gh:

It's wired up as one of the lazy-loading mise stubs, so the first time you run gh, it installs itself.

Migration 1784909971.sh ("Regenerate mise wrappers to stop them recursing through PATH") is the only recovery path. It derives the list of packages by iterating the wrappers that already exist:

for wrapper in "$HOME/.local/bin"/*; do
  [[ -f $wrapper && -x $wrapper ]] || continue
  package=$(sed -n 's/^mise use -g "\(.*\)"$/\1/p' "$wrapper")
  ...
  omarchy-mise-install "$package" "$(basename "$wrapper")" "$bin"
done

There is no canonical list of expected stubs stored anywhere in the repo. Once ~/.local/bin is empty the glob does not expand, the loop finds nothing, and no migration recreates anything.

Impact

Clearing ~/.local/bin — a routine cleanup — permanently destroys all 15 stubs. The documented gh auto-install silently stops working with gh: command not found, with no error, warning, or log line. Users cannot recover without re-running omarchy-mise-install by hand.

Note that migrations/1786183928.sh ("Refresh mise stubs so tools take new releases immediately") does not help either: it only calls omarchy-refresh-applications.

Reproduction

rm -rf ~/.local/bin/*
omarchy update          # runs all migrations
gh --version            # gh: command not found

Verified on Omarchy 4.0.4, kernel 7.2.5-3-omarchy.

Suggested fix

Store the canonical stub list (a data file, or by re-running the omarchy-mise-install lines from install/user/mise.sh) and have 1784909971.sh iterate that list rather than the existing filesystem state, so stubs are restored idempotently on every update.

Same migration, different failure modes already reported: #13040, #11973, #11971, #13677, #13177, #10300.

View raw text

## Problem

`install/user/mise.sh` creates 15 lazy-install stubs in `~/.local/bin/` via `omarchy-mise-install`. Each wrapper runs `mise use -g <pkg>` on first execution, so the tool installs itself.

`manual/18-development-tools.md` documents this for `gh`:

> It's wired up as one of the lazy-loading mise stubs, so the first time you run `gh`, it installs itself.

Migration `1784909971.sh` ("Regenerate mise wrappers to stop them recursing through PATH") is the only recovery path. It derives the list of packages **by iterating the wrappers that already exist**:

```bash
for wrapper in "$HOME/.local/bin"/*; do
[[ -f $wrapper && -x $wrapper ]] || continue
package=$(sed -n 's/^mise use -g "$.*$"$/\1/p' "$wrapper")
...
omarchy-mise-install "$package" "$(basename "$wrapper")" "$bin"
done
```

There is no canonical list of expected stubs stored anywhere in the repo. Once `~/.local/bin` is empty the glob does not expand, the loop finds nothing, and no migration recreates anything.

## Impact

Clearing `~/.local/bin` — a routine cleanup — permanently destroys all 15 stubs. The documented `gh` auto-install silently stops working with `gh: command not found`, with no error, warning, or log line. Users cannot recover without re-running `omarchy-mise-install` by hand.

Note that `migrations/1786183928.sh` ("Refresh mise stubs so tools take new releases immediately") does not help either: it only calls `omarchy-refresh-applications`.

## Reproduction

```bash
rm -rf ~/.local/bin/*
omarchy update # runs all migrations
gh --version # gh: command not found
```

Verified on Omarchy 4.0.4, kernel 7.2.5-3-omarchy.

## Suggested fix

Store the canonical stub list (a data file, or by re-running the `omarchy-mise-install` lines from `install/user/mise.sh`) and have `1784909971.sh` iterate that list rather than the existing filesystem state, so stubs are restored idempotently on every update.

## Related

Same migration, different failure modes already reported: #13040, #11973, #11971, #13677, #13177, #10300.

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 20:08 UTC

Proof

History & reports

Reference