Separate from #6948 (invalid `config.toml`) — same generated wrappers, different failure. This one presents as a **hang** rather than an error, so it is easy to misattribute to the network or to the tool being probed.

### Mechanism

`omarchy-mise-install` generates:

```bash
#!/bin/bash
export MISE_MINIMUM_RELEASE_AGE=0
mise use -g "codex" || exit 1
exec mise x "codex" -- "codex" "$@"
```

That final `codex` is resolved by `mise x` through `PATH` — and `~/.local/bin/codex` **is** the wrapper, sitting on that same `PATH`. When mise does not place its install dir ahead of `~/.local/bin`, the wrapper execs itself.

Because it is `exec`, the process count never grows. There is no fork bomb to spot in `htop`: one process spins, and whatever launched it eventually gives up.

PATH lookup inside `mise x` does find the wrapper:

```
$ mise x codex -- sh -c 'command -v codex'
/home/you/.local/bin/codex
```

### Evidence

I added a depth counter to the wrapper, exported so it survives `exec` (an exec loop should therefore show a **constant pid at rising depth**), bounded at 40, and let T3 Code probe its Codex provider:

```
2026-08-18T15:09:05 depth=1   pid=1459179  argv=app-server
2026-08-18T15:09:05 depth=2   pid=1459179  argv=app-server
...
2026-08-18T15:09:05 depth=40  pid=1459179  argv=app-server
2026-08-18T15:09:05 ABORT at depth 40
```

Same pid, depth 1 → 40. Five such chains in one session (206 log lines, 5 aborts): three `app-server` probes, one `-s read-only -a untrusted app-server`, and one with empty argv.

Unbounded, the app reports:

> Timed out while checking Codex app-server provider status.

With the bound in place it becomes:

> Codex app-server provider probe failed: Codex App Server process exited with code 90.

(90 being the deliberate abort — which is what confirms the loop is real and not an artifact of instrumentation.)

### I could not reproduce it from a shell

`~/.local/bin/codex --version` from an interactive shell gives `depth=1` and exits correctly, every time. Things I tried and which did **not** reproduce it:

- cwd variations, including a directory containing `.mise.toml`
- a `PATH` emulating an already-activated mise environment, with `installs/<tool>/...` dirs present and `~/.local/bin` ahead of them
- `__MISE_ORIG_PATH`, `MISE_SHELL`, `__MISE_SESSION` set
- replaying the spawning app's exact environment captured from `/proc/<pid>/environ`

It reproduces reliably when the app itself spawns the wrapper. So something about that spawn makes `mise x` fall back to a PATH lookup for its final argument instead of resolving the tool itself, and I have not identified what. Flagging that gap explicitly rather than guessing.

### Suggested fix

Stop the wrapper from being able to resolve its own name. Either exec the resolved binary directly:

```bash
exec "$(mise which "$bin")" "$@"
```

or keep `mise x` and add a re-entry guard:

```bash
__mw=_MISE_WRAP_$(printf %s "$package" | tr -c "A-Za-z0-9" _)
if [[ -n ${!__mw:-} ]]; then
  __real=$(mise which "$bin" 2>/dev/null)
  [[ -n $__real && -x $__real ]] && exec "$__real" "$@"
  exit 127
fi
export "$__mw=1"
```

The guard has a useful side effect: it also covers tools that shell out to their own name. `codex` spawns `codex exec ...`, which otherwise re-enters the wrapper too.

Guarding all 13 wrappers fixed it here, and the provider has been stable since.

Worth noting that migration `1784909971.sh` is already titled *"Regenerate mise wrappers to stop them recursing through PATH"*, so this shape of bug has bitten before.

### Environment

- Omarchy 4.0.0-1, Arch
- mise 2026.8.3
- codex-cli 0.147.0
- Triggering app: T3 Code 0.0.33, which spawns provider probes on a 10s budget