Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA 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.
mise wrappers loop forever when ~/.local/bin is ahead of mise tool dirs in PATH
Reported by OgnjenKop · filed Oct 10, 2026 · open at source
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
Summary
The wrappers that omarchy-mise-install writes to ~/.local/bin (grok, opencode, pi, omp, cursor-agent, gh, …) hang forever at 100% CPU when ~/.local/bin comes before the mise tool directories in PATH. Inside mise x <pkg> -- <bin>, the bare <bin> resolves back to the wrapper, which runs mise x again under the same PID, and so on. Nothing is printed and nothing exits.
Omarchy's env-bootstrap appends ~/.local/bin on purpose. But third-party installers often prepend it in ~/.bashrc / ~/.bash_profile. In my case it was the Antigravity CLI installer:
# Added by Antigravity CLI installer
export PATH="/home/<user>/.local/bin:$PATH"Once that line is there, every Omarchy mise wrapper silently hangs, including in any app that inherits the login-shell PATH. Agent IDEs that probe these CLIs then show providers with no models.
Environment
- omarchy 4.0.4-1
- mise-bin 2026.10.4-1 (the recursion fix in mise v2026.3.8 doesn't cover this case)
Reproduce
PATH="$HOME/.local/bin:$PATH" timeout 10 grok --version; echo "exit=$?"
# exit=124 (hangs)
mise x npm:@xai-official/grok -- sh -c 'command -v grok'
# /home/<user>/.local/bin/grok <- the wrapper, not the real binarySuggested fix
In omarchy-mise-install, have the generated wrapper drop ~/.local/bin from PATH before calling mise. Then the wrapper can't resolve to itself, whatever order the user's PATH is in:
#!/bin/bash
export MISE_MINIMUM_RELEASE_AGE=0
PATH=":$PATH:"; PATH="${PATH//:$HOME\/.local\/bin:/:}"; PATH="${PATH#:}"; PATH="${PATH%:}"
mise use -g --quiet "npm:@xai-official/grok" || exit 1
exec mise x "npm:@xai-official/grok" -- "grok" "$@"I tested this locally with ~/.local/bin first in PATH: the patched wrapper returns right away, and the current one hangs. A migration that re-runs omarchy-mise-install for existing wrappers (like 1784909971.sh does) would roll it out.
Alternatively or additionally, omarchy-mise-install or a doctor command could warn when ~/.local/bin comes before mise's directories in PATH.
View raw text
## Summary
The wrappers that `omarchy-mise-install` writes to `~/.local/bin` (grok, opencode, pi, omp, cursor-agent, gh, …) hang forever at 100% CPU when `~/.local/bin` comes before the mise tool directories in `PATH`. Inside `mise x <pkg> -- <bin>`, the bare `<bin>` resolves back to the wrapper, which runs `mise x` again under the same PID, and so on. Nothing is printed and nothing exits.
Omarchy's `env-bootstrap` appends `~/.local/bin` on purpose. But third-party installers often prepend it in `~/.bashrc` / `~/.bash_profile`. In my case it was the Antigravity CLI installer:
```bash
# Added by Antigravity CLI installer
export PATH="/home/<user>/.local/bin:$PATH"
```
Once that line is there, every Omarchy mise wrapper silently hangs, including in any app that inherits the login-shell PATH. Agent IDEs that probe these CLIs then show providers with no models.
## Environment
- omarchy 4.0.4-1
- mise-bin 2026.10.4-1 (the recursion fix in mise v2026.3.8 doesn't cover this case)
## Reproduce
```bash
PATH="$HOME/.local/bin:$PATH" timeout 10 grok --version; echo "exit=$?"
# exit=124 (hangs)
mise x npm:@xai-official/grok -- sh -c 'command -v grok'
# /home/<user>/.local/bin/grok <- the wrapper, not the real binary
```
## Suggested fix
In `omarchy-mise-install`, have the generated wrapper drop `~/.local/bin` from `PATH` before calling mise. Then the wrapper can't resolve to itself, whatever order the user's PATH is in:
```bash
#!/bin/bash
export MISE_MINIMUM_RELEASE_AGE=0
PATH=":$PATH:"; PATH="${PATH//:$HOME\/.local\/bin:/:}"; PATH="${PATH#:}"; PATH="${PATH%:}"
mise use -g --quiet "npm:@xai-official/grok" || exit 1
exec mise x "npm:@xai-official/grok" -- "grok" "$@"
```
I tested this locally with `~/.local/bin` first in PATH: the patched wrapper returns right away, and the current one hangs. A migration that re-runs `omarchy-mise-install` for existing wrappers (like `1784909971.sh` does) would roll it out.
Alternatively or additionally, `omarchy-mise-install` or a doctor command could warn when `~/.local/bin` comes before mise's directories in PATH.
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-10 12:53 UTC