## System details

Omarchy on Linux x86_64, kernel `7.2.5-3-omarchy`; `/etc/os-release` reports `VERSION_ID=4.0.4` while `/usr/share/omarchy/version` reports `4.0.0.alpha` (recording both rather than guessing). Mise `2026.9.16`; omp `18.8.2` after recovery.

## What's wrong?

The configured mise omp installation and a standalone executable at `~/.local/bin/omp` can coexist silently. The standalone location is also where Omarchy puts its mise launcher. Updating one owner does not establish that every shell/launcher now resolves the same installation; equal versions can mask the ownership conflict until the next update.

On this workstation, `github:can1357/oh-my-pi = "latest"` was in global mise configuration, while `~/.local/bin/omp` was a standalone ELF rather than Omarchy's launcher. Both later reported 18.8.2. The creator of the standalone file was **not established**. This report does not claim that omp's updater created it, that mise failed to upgrade, or that every standalone installation is wrong. Omp 18.6.3 already routes mise-owned update targets through mise.

This is a proposal for a **non-destructive ownership-drift warning**, based on that verified state, not a request to automatically overwrite user executables.

## Verified behavior and safe reproduction

1. Configure mise to own `github:can1357/oh-my-pi` and install it.
2. Have a separate executable `omp` at the default standalone location, an explicit `PI_INSTALL_DIR`, or another PATH entry.
3. Run a mise update that has no new version to install.
4. There is no ownership warning. The separate executable remains untouched.

I reproduced step 3 in a disposable HOME/config with `github:can1357/oh-my-pi = "18.8.2"`, an already-installed real mise binary, and a non-executed ELF-prefix fixture at the standalone path. Native `mise upgrade github:can1357/oh-my-pi` printed:

```text
mise All tools are up to date
```

No ownership warning was emitted and the fixture was unchanged. I did not rerun a network installer over a live launcher to reproduce the state.

## Proposed official integration

Add an ownership checker at the explicit mise-update workflow seam, not an automatic launcher rewrite:

1. For a tool actually selected/configured as mise-owned, inspect its known standalone path and executable PATH candidates. Start with omp's `github:can1357/oh-my-pi` mapping; do not warn on standalone-only installations without a mise ownership claim.
2. Run it before `mise up` in `omarchy-update-mise`, even when nothing is outdated. An optional named hook such as `pre-update-mise` would also let users extend the check without editing vendor scripts.
3. Include a supported global mise batch-install hook for ordinary installs/real upgrades. For direct mise users, an optional guarded update task must be invoked with `mise run --skip-tools update` (or an invocation-local `MISE_TASK_RUN_AUTO_INSTALL=false`). Otherwise mise can install missing configured tools before the checker starts; a failed implicit install can prevent the check entirely. Do not change global auto-install defaults for unrelated tasks. Mise's current install hooks do **not** guarantee invocation for no-op upgrades or dry runs; do not advertise them as a universal upgrade hook.
4. Route the update alias/workflow through the guarded seam if an always-check guarantee is wanted. Preserve the native upgrade's arguments, release-age behavior, exit status, and shell activation function.
5. Print stderr warnings naming conflicting paths and owner-specific recovery guidance. Continue the update. Never delete, rewrite, execute, or ask an unrecognized candidate for its version.

Expected diagnostic:

```text
WARNING: omp ownership conflict: mise is configured to own omp.
  ~/.local/bin/omp: standalone executable outside mise's omp installation.
Mise upgrades will not update this separate executable.
Inspect/preserve custom files before deliberately restoring Omarchy's launcher.
```

The checker must accept canonical Omarchy mise launchers, mise's omp versioned binaries/symlinks, and native mise shims that resolve to mise itself. It should support XDG/custom mise data roots, deduplicate repeated resolved paths, and warn even when versions happen to match. Do not deduplicate by inode before ownership classification: an external hard link to a managed binary is independently pinned when mise changes versions and must still warn. Unknown custom wrappers should be described as unrecognized ownership, not falsely asserted to be standalone-installer output. No unbounded filesystem scan is needed.

## Local implementation and verification

[MooseGooseConsulting/coldaine-configurations#52](https://github.com/MooseGooseConsulting/coldaine-configurations/pull/52) contains a scoped opt-in implementation, rationale, and recovery policy. The local canonical launcher and warning kit are already applied. It uses supported mise config fragments, a guarded task invoked with `mise run --skip-tools update`, and the existing Omarchy `post-update.d` hook (which currently runs before the mise phase); an official checker directly in `omarchy-update-mise` would be the cleaner seam.

- Thirteen regressions now pass, including external hard-link candidate ordering, executable global file-task collision refusal, and early checking with a missing configured tool in an isolated offline HOME.
- Live guarded no-op update, dry run, no-op native install, and Omarchy hook all emitted the expected foreign-candidate warning.
- Healthy mise launcher/binaries were silent.
- Foreign executable was neither run nor changed; native upgrade exit status was preserved.
- Launcher recovery used `omarchy-mise-install github:can1357/oh-my-pi omp`; it reported `omp/18.8.2` afterward.

This warning mitigates rediscovery/confusion; it does not prevent another installer from replacing a launcher later. The PR documents raw no-op `mise up` limitations instead of concealing them.

## Related sources

- [Omarchy AI manual](https://omarchy.org/manual/ai/) documents the lazy mise-backed agent launchers.
- [Provisioning at 060c57b4](https://github.com/omacom/omarchy/blob/060c57b4aa416022343893c1a2e4eadae255257e/install/user/mise.sh) wires omp through `omarchy-mise-install`.
- [Update orchestration at 060c57b4](https://github.com/omacom/omarchy/blob/060c57b4aa416022343893c1a2e4eadae255257e/bin/omarchy-update) runs `post-update` before `omarchy-update-mise`.
- [Mise hooks at 2184db81](https://github.com/jdx/mise/blob/2184db810a7e2c29475abdba53e5af910e96859a/docs/hooks.md) describe install hooks but no no-op-upgrade event. [Hook implementation](https://github.com/jdx/mise/blob/2184db810a7e2c29475abdba53e5af910e96859a/src/hooks.rs) at that revision has no experimental gate; [task preparation](https://github.com/jdx/mise/blob/2184db810a7e2c29475abdba53e5af910e96859a/src/cli/run.rs) precedes task scripts unless disabled.
- #7101 concerns destructive wrapper replacement; this proposal deliberately avoids that approach and does not claim to fix that issue.

## PR-review refinements (2026-10-07)

The central recommendation is unchanged: a non-destructive check directly in `omarchy-update-mise`, before native `mise up`. Review strengthens that preference over a global task: direct integration avoids pre-task automatic tool installation and collisions with existing global file-based `update` tasks. An official task installer must check both TOML and file-task sources before claiming a name.

The detector now distinguishes independently pinned external hard links instead of letting a previously seen managed inode hide them. A live hard link to the actual managed omp binary warned with the managed candidate first; the guarded dry run, native no-op install, and isolated kit hook all passed with `MISE_EXPERIMENTAL=false`. Healthy ownership was silent. The local kit declares mise 2026.9.16+ compatibility rather than enabling experimental features or assuming older releases behave identically.