# Lingtai Update Detection

> Use when determining how the running lingtai-tui was installed.

- Skill: `lingtai-ai/lingtai-update-detection` (Agent Skill)
- Install (CLI): `npx skillmds@latest add lingtai-ai/lingtai-update-detection`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lingtai-ai/lingtai-update-detection/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: lingtai-ai (https://skillmd.com/u/lingtai-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lingtai-ai/lingtai-update-detection

---


# Install-method detection

Nested `lingtai-update` reference. Detection is deliberately conservative.

1. Read `~/.lingtai-tui/install.json` (or the configured global directory) and
   validate the `lingtai.tui.install/v1` metadata. Matching the running
   executable, including the managed `lingtai-tui` alias, makes this a
   source/user-local install.
2. Otherwise, recognize Homebrew from the executable path and Homebrew
   prefixes/environment, including `/opt/homebrew`, `/usr/local`, and
   `/home/linuxbrew/.linuxbrew` patterns.
3. Otherwise classify it as unknown/other. Do not run `brew` merely because it
   is available, and do not infer source ownership from a path alone when
   source metadata says otherwise.

Symlinks matter: a manually linked or development binary may not be the
Homebrew Cellar copy. Check `lingtai-tui doctor` output and the resolved
executable before choosing a manual command. This metadata is diagnostic and
routing information, not a credential store.

A Homebrew-detected install is not upgraded through brew: `/update-tui` and
`lingtai-tui self-update` migrate it to the native installer instead (see
`reference/update-tui/SKILL.md`). Migrating installs and verifies a native
binary, but does not by itself guarantee the shell will run it: on a standard
Apple-Silicon Homebrew host, `/opt/homebrew/bin` is earlier on PATH than
install.sh's default native bin dir, so the resolved `lingtai-tui` can still
be the old Homebrew one even after a "successful" install. Detection accounts
for this directly — when valid native (`install.json`) metadata exists but
does not match the currently resolved executable, and that executable still
resolves as Homebrew, detection reports `DuplicateNativeInstall` instead of
silently treating it as a plain fresh Homebrew install: the method stays
Homebrew (the resolved binary really is still Homebrew's), and every update
entry point surfaces "native installed, migration not complete, remove
Homebrew yourself" instead of re-prompting or re-running the installer. Only
once the resolved executable actually matches the native metadata does
detection report the install as source/user-local from then on — until then,
the Homebrew Cellar copy stays on disk. Removing it always requires a
concrete interactive "y" to the "Remove the old Homebrew installation now?"
prompt at startup (see `reference/update-tui/SKILL.md`); `self-update` and
`doctor` never uninstall it themselves, only report the manual command.