fix(tui): avoid update loops for mismatched npm installs

[fcoury-oai]

Why

Users with more than one Codex install can get stuck in a misleading update loop: the running CLI offers an update, but the updater mutates a different install than the executable their shell will launch next. For npm-managed installs, a successful npm install -g @openai/codex is not enough to prove that the active codex command now points at the updated package.

And when the user chooses Help me fix this it starts a new session with:

Help me fix my Codex install. Codex is currently running from /Users/felipe.coury/.local/bin, but npm install -g @openai/codex@latest would update /Users/felipe.coury/.local/share/mise/installs/node/24.14.1/lib/node_modules/@openai/codex. Please inspect my shell PATH and Codex installs, explain the safest fix, and ask before making any destructive changes.

What changed

• Preserve npm launch provenance from the JS shim via CODEX_MANAGED_PACKAGE_ROOT, then compare that running package root with the package root npm install -g would update.

• When Codex can prove those roots differ, replace the misleading update flow with remediation UX:

  • bare launches show an actionable popup with Help me fix this, Later, and Don't remind me about this version

  • prompt-bearing launches show a subdued inline warning instead of interrupting the user's task

  • Help me fix this starts a Codex session with a prefilled diagnostic prompt that asks before destructive changes

• When a prompt-driven update reports success but the next launch is still the same old executable, treat that as a likely no-op update:

  • bare launches show the richer remediation popup

  • prompt-bearing launches show a one-time inline warning while preserving the later popup opportunity

• Reuse the same mismatch detection in codex update, and persist just enough state to avoid repeated no-op inline warnings for the same target version.

How to Test

1. Set up two npm-managed Codex installs in different prefixes, with an older install first on PATH while npm root -g points at the other prefix.

2. Start bare codex from the older install and confirm the remediation popup identifies both package roots instead of offering a misleading update.

3. Choose Help me fix this and confirm Codex starts a session with a prefilled repair prompt that asks it to inspect PATH / install state before changing anything.

4. Start codex "summarize recent commits" in the same mismatched environment and confirm startup stays non-blocking while showing the subdued inline warning.

5. Trigger a prompt-driven update that completes without changing the executable used on the next launch:

   • on the next prompt-bearing launch, confirm Codex shows the one-time inline no-op warning

   • on the next bare launch, confirm Codex still shows the remediation popup

6. Run codex update from the mismatched shell and confirm it exits with remediation text instead of running the wrong updater.

Manual validation performed:

• Reproduced the original loop with two disposable npm prefixes in tmux:

  • the launched CLI stayed on 0.129.0

  • npm install -g updated the other prefix to 0.130.0

  • relaunching the same codex command showed the same update prompt again

• Locally smoke-tested the new mismatch path by temporarily making the debug build eligible for startup update checks:

  • changed the workspace version from 0.0.0 to 0.129.0

  • temporarily widened the debug-only update gates so the debug binary included the startup flow

  • launched the branch build with:

    CODEX_MANAGED_BY_NPM=1 \
    CODEX_MANAGED_PACKAGE_ROOT="$HOME/.local/bin" \
    ./target/debug/codex resume --last

  • with npm still rooted at the mise-managed install, this exercised the remediation path against the real local mismatch between $HOME/.local/bin and the npm global package root

• The fake-version and debug-gate edits were smoke-only local changes and are not part of this PR.

Targeted tests:

• cargo test -p codex-tui update_action

• cargo test -p codex-tui update_

• cargo test -p codex-tui no_op_inline_notice_marker_is_persisted_without_clearing_remediation

• cargo test -p codex-cli update_