v1.2.3 — MDM: detect CLIs & persist token in the logged-in user's context

Fixes two silent MDM failures on macOS/Linux. Both had the same root cause: under MDM the binary runs elevated (root via launchd/systemd), and it was using that elevated/daemon context instead of the logged-in user's — so it couldn't see per-user installs or write to the user's home. Both now resolve against the logged-in user (the same principle v1.2.2 applied to Claude Desktop detection).

Fixes

• CLI detection under MDM (Claude Code / Codex). toolInstalled used the elevated process's PATH, which under launchd is minimal (/usr/bin:/bin:/usr/sbin:/sbin) and misses every per-user install — Homebrew (/opt/homebrew/bin, /usr/local/bin), npm-global, nvm, ~/.local/bin. --claude-code/--codex (and auto-detect) therefore reported the CLIs not installed and skipped them, leaving them ungoverned while the run exited 0. Detection now runs command -v in the logged-in user's interactive login shell (sudo -H -u <user> <login-shell> -ilc …), with a fallback to the elevated PATH for system-wide installs and an 8s timeout. (An interactive sudo test masked this; launchd's minimal PATH did not.)
• Refresh token not persisted → browser login every run. The token child was re-exec'd with sudo -u <user> (no -H), inheriting the daemon's HOME=/var/root; the default token path ~/.tf resolved to /var/root/.tf, which the user can't write (mkdir /var/root/.tf: permission denied), so the refresh token was never cached. Added -H so ~/.tf resolves to the user's home and the token persists for silent refresh.

Merged PRs

• Detect CLIs and persist tokens in the logged-in user's context (MDM fix) (source#10)

Full changelog: v1.2.2...v1.2.3

Assets

Prebuilt binaries for macOS (arm64/amd64), Linux (amd64), and Windows (amd64), built from source main @ 7a2e962 with -trimpath -ldflags="-s -w".