Closing: current main already covers this as of b6fbd181ca. If you still see it on a build that includes that commit, reply and we'll reopen.
[Bug]: "Install t3 command" says T3's own launcher shadows itself when ~/.t3/bin is on PATH (Linux/macOS)#22361
What happens
On Linux, Settings → install the t3 command fails with:
| 1 | Error invoking remote method 'desktop:cli-command-install': DesktopCliCommandError: Another t3 at /home/<user>/.t3/bin/t3 runs first in a new terminal. Remove it, or run the launcher directly at /home/<user>/.t3/bin/t3. |
The "other" t3 and the launcher are the same file.
Cause
apps/desktop/src/app/DesktopCliCommand.ts: foreignFirstOnPath takes the first t3 on process.env.PATH and treats it as foreign unless isOurLink returns true. isOurLink starts with fs.readLink(link), so it only accepts a symlink to the launcher. The launcher itself (~/.t3/bin/t3, written by DesktopCliShim) is a regular file. When ~/.t3/bin comes first on PATH, readLink fails, isOurLink returns false, and install refuses with the launcher's own path. state reports shadowedBy and onPath: false for the same reason, so the Settings row warns too.
Repro
- Linux, packaged nightly. Put
export PATH="$HOME/.t3/bin:$PATH"in~/.bashrc(or start the app from a shell where~/.t3/binis on PATH). - Start T3 Code so it inherits that PATH.
- Settings → install the t3 command → error above.
Suggested fix
In foreignFirstOnPath (and the onPath check in state), treat the first match as ours when it is the launcher: first.value === launcher, or compare realPath. Or let isOurLink accept a regular file that contains DesktopCliShim.MARKER. Add a test where binDirectory is first on PATH.
Environment
- T3 Code nightly (desktop) at
/usr/lib/t3code-nightly, Omarchy (Arch Linux), Wayland - Code checked at
main67c0fc0cda (2026-10-20). The check came in with #17351.