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

mise wrappers perform global install/config writes on every command invocation

Reported by LoonanChauvette · filed Sep 15, 2026 · 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 wrappers perform global install/config writes on every command invocationrevision 1 · captured 2026-09-28 21:23 UTC via poll

Bug description

omarchy-mise-install generates wrappers that perform installation/global configuration mutation on every ordinary command invocation:

export MISE_MINIMUM_RELEASE_AGE=0
mise use -g --quiet "$package" || exit 1
exec mise x "$package" -- "$bin" "$@"

This mixes two lifecycle operations:

  1. install/update/configure the tool;
  2. execute the tool.

A read-only command such as gh auth status therefore rewrites global mise configuration and may perform release/install work before it runs GitHub CLI.

Observed impact

Hermes Desktop periodically probes gh auth status with a ten-second timeout. If the wrapper is killed while waiting for its mise use child, that descendant can survive, retain shared mise state/locks, and block later calls. On one Omarchy 4.0.3 system this accumulated roughly 20 old gh/mise processes, several near one CPU each, and pushed load into the double digits.

The same generated shape is used for ghui and other tools, so the problem is not specific to GitHub authentication.

This is related to #7426 (stdout corruption) and #7360 (wrapper recursion), but distinct: even with --quiet and no recursion, ordinary execution remains state-changing and timeout-hostile.

Expected behavior

Running a generated command should only execute the already-installed tool. Installation, version resolution, and global configuration writes should occur during Omarchy installation/update/refresh—not on every invocation.

Suggested direction

  • Resolve/install the desired version when omarchy-mise-install runs.
  • Generate a read-only wrapper afterward, preferably executing the resolved binary directly or using an invocation mode that cannot resolve back to the wrapper.
  • Keep first-run installation as an explicit fallback only if no installed binary exists.
  • Publish wrapper changes atomically.

For example, conceptually:

mise use -g --quiet "$package"       # once, in omarchy-mise-install
real=$(mise which "$bin")
# generated wrapper: exec "$real" "$@"

The exact implementation should preserve Omarchy's intended automatic update cadence without putting mutation in the command hot path.

Environment

  • Omarchy 4.0.3-1
  • mise 2026.9.4
  • GitHub CLI 2.100.0
  • Arch Linux
View raw text
## Bug description

`omarchy-mise-install` generates wrappers that perform installation/global configuration mutation on every ordinary command invocation:

```bash
export MISE_MINIMUM_RELEASE_AGE=0
mise use -g --quiet "$package" || exit 1
exec mise x "$package" -- "$bin" "$@"
```

This mixes two lifecycle operations:

1. install/update/configure the tool;
2. execute the tool.

A read-only command such as `gh auth status` therefore rewrites global mise configuration and may perform release/install work before it runs GitHub CLI.

## Observed impact

Hermes Desktop periodically probes `gh auth status` with a ten-second timeout. If the wrapper is killed while waiting for its `mise use` child, that descendant can survive, retain shared mise state/locks, and block later calls. On one Omarchy 4.0.3 system this accumulated roughly 20 old `gh`/mise processes, several near one CPU each, and pushed load into the double digits.

The same generated shape is used for `ghui` and other tools, so the problem is not specific to GitHub authentication.

This is related to #7426 (stdout corruption) and #7360 (wrapper recursion), but distinct: even with `--quiet` and no recursion, ordinary execution remains state-changing and timeout-hostile.

## Expected behavior

Running a generated command should only execute the already-installed tool. Installation, version resolution, and global configuration writes should occur during Omarchy installation/update/refresh—not on every invocation.

## Suggested direction

- Resolve/install the desired version when `omarchy-mise-install` runs.
- Generate a read-only wrapper afterward, preferably executing the resolved binary directly or using an invocation mode that cannot resolve back to the wrapper.
- Keep first-run installation as an explicit fallback only if no installed binary exists.
- Publish wrapper changes atomically.

For example, conceptually:

```bash
mise use -g --quiet "$package"       # once, in omarchy-mise-install
real=$(mise which "$bin")
# generated wrapper: exec "$real" "$@"
```

The exact implementation should preserve Omarchy's intended automatic update cadence without putting mutation in the command hot path.

## Environment

- Omarchy 4.0.3-1
- mise 2026.9.4
- GitHub CLI 2.100.0
- Arch Linux

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 13:37 UTC