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-2158GitHub issuePublicFixed

mise wrapper stubs from before the --quiet template fix pollute stdout; no migration refreshes them

Reported by howiehu · filed Oct 1, 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 wrapper stubs from before the --quiet template fix pollute stdout; no migration refreshes themrevision 1 · captured 2026-10-01 22:01 UTC via poll

What's wrong?

~/.local/bin CLI stubs written by omarchy-mise-install before the template gained --quiet still run mise use -g <pkg> without it on every invocation, and mise prints its status line to stdout:

$ cat ~/.local/bin/gh        # stub written 2026-08-18, omarchy ≤ 4.0.1 era
#!/bin/bash
export MISE_MINIMUM_RELEASE_AGE=0
mise use -g "gh" || exit 1
exec mise x "gh" -- "gh" "$@"

$ gh --version 2>/dev/null
mise ~/.config/mise/config.toml tools: [email protected]
gh version 2.102.0 (2026-09-30)
https://github.com/cli/cli/releases/tag/v2.102.0

Everything that consumes these CLIs' stdout breaks: $(...) captures, redirects, pipes, JSON parsing. Concrete casualties on my machine: scripted gh --json output became unparseable, and a gh pr edit --body-file round-trip published the status line into live PR descriptions.

Verified behavior on mise 2026.9.14: mise use without --quiet emits the status line on stdout; mise use --quiet does not; plain mise x with the tool already installed does not.

Why it survives upgrades

  • The current template is already fixed (mise use -g --quiet … || exit 1 — /usr/share/omarchy/bin/omarchy-mise-install, the heredoc around lines 52–57).
  • But stubs are only written when their install command/migration runs and the command is missing (e.g. omarchy-cmd-missing muse && …). An existing stub is never refreshed.
  • Timeline from my machine (pacman.log + stub mtimes): 12 stubs (gh, claude, codex, copilot, crush, gemini, ghui, grok, hunk, opencode, pi, playwright) written 2026-08-18 under ≤ 4.0.1. The 4.0.3 upgrade on 2026-09-09 wrote a fresh muse stub via migration 1788724825 (16 seconds after the package upgrade, with --quiet — clean), while the older stubs kept the polluting body and will keep it forever.

Suggested fix

Ship a migration that regenerates existing omarchy-mise-install stubs in ~/.local/bin, like migration 1784909971 ("Regenerate mise wrappers to stop them recursing through PATH") already does — it loops over ~/.local/bin and rewrites matching wrappers via omarchy-mise-install.

Workaround applied locally

Re-ran omarchy-mise-install for the 12 stale stubs; stdout/stderr verified clean afterwards. Anything that refreshes stubs on upgrade would remove the need for that manual step.

System details

Omarchy 4.0.4-1, mise 2026.9.14 (linux-x64), AMD Ryzen 7 8745HS with Radeon 780M iGPU.

View raw text
## What's wrong?

`~/.local/bin` CLI stubs written by `omarchy-mise-install` **before** the template gained `--quiet` still run `mise use -g <pkg>` without it on every invocation, and mise prints its status line to **stdout**:

```console
$ cat ~/.local/bin/gh        # stub written 2026-08-18, omarchy ≤ 4.0.1 era
#!/bin/bash
export MISE_MINIMUM_RELEASE_AGE=0
mise use -g "gh" || exit 1
exec mise x "gh" -- "gh" "$@"

$ gh --version 2>/dev/null
mise ~/.config/mise/config.toml tools: [email protected]
gh version 2.102.0 (2026-09-30)
https://github.com/cli/cli/releases/tag/v2.102.0
```

Everything that consumes these CLIs' stdout breaks: `$(...)` captures, redirects, pipes, JSON parsing. Concrete casualties on my machine: scripted `gh --json` output became unparseable, and a `gh pr edit --body-file` round-trip published the status line into live PR descriptions.

Verified behavior on mise 2026.9.14: `mise use` without `--quiet` emits the status line on stdout; `mise use --quiet` does not; plain `mise x` with the tool already installed does not.

## Why it survives upgrades

- The current template is already fixed (`mise use -g --quiet … || exit 1` — `/usr/share/omarchy/bin/omarchy-mise-install`, the heredoc around lines 52–57).
- But stubs are only written when their install command/migration runs and the command is missing (e.g. `omarchy-cmd-missing muse && …`). An existing stub is never refreshed.
- Timeline from my machine (pacman.log + stub mtimes): 12 stubs (gh, claude, codex, copilot, crush, gemini, ghui, grok, hunk, opencode, pi, playwright) written 2026-08-18 under ≤ 4.0.1. The 4.0.3 upgrade on 2026-09-09 wrote a fresh `muse` stub via migration 1788724825 (16 seconds after the package upgrade, with `--quiet` — clean), while the older stubs kept the polluting body and will keep it forever.

## Suggested fix

Ship a migration that regenerates existing `omarchy-mise-install` stubs in `~/.local/bin`, like migration 1784909971 ("Regenerate mise wrappers to stop them recursing through PATH") already does — it loops over `~/.local/bin` and rewrites matching wrappers via `omarchy-mise-install`.

## Workaround applied locally

Re-ran `omarchy-mise-install` for the 12 stale stubs; stdout/stderr verified clean afterwards. Anything that refreshes stubs on upgrade would remove the need for that manual step.


### System details

Omarchy 4.0.4-1, mise 2026.9.14 (linux-x64), AMD Ryzen 7 8745HS with Radeon 780M iGPU.

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

  • Fixed bypr/11514· confirmed

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:32 UTC