Settings offers an Install button for the t3 command that can only fail when another t3 is first on PATH #27093

What happened

In Settings → About I clicked to install the t3 CLI but got an error. Shouldn't it show that it's installed? It seems it's already installed.

t3 already worked in a terminal. The Settings row still offered Install, and clicking it only produced an error toast.

Diagnosis

~/.local/bin/t3 was a hand-written wrapper that ran the CLI bundled in the AppImage, the same bin.mjs the app's launcher runs. It was first on PATH.

DesktopCliCommand handles this as designed since #17351: state reports it as shadowedBy, and install refuses to link behind it. The problem is the Settings row. In apps/web/src/components/settings/CliCommandSettingsRow.tsx, when shadowedBy is set and installedPath is null, the row still shows an enabled Install button. Every click runs install, which fails with the same message the row description already shows, and the result is an error toast. From the user's side, this reads as "the app is broken", not "you already have a t3".

I checked main at 2026-10-29, after #22375 and #22046. Those changes make the app recognize its own launcher, but any other t3 is still foreign, and the row component is unchanged. So main behaves the same way. By the same code path, a macOS wrapper that only does exec "$HOME/.t3/bin/t3" "$@" also counts as foreign, because its real path differs from the launcher's. I read this in the source and did not click through it on a Mac.

A possible fix: when shadowedBy is set and nothing is installed, drop or disable the Install button and let the description explain what is on PATH, instead of offering an action that can only fail.

Steps to reproduce

1. Linux, packaged desktop AppImage 0.1.5, with ~/.local/bin on PATH.
2. Put any executable t3 there that the app did not create, for example:
   printf '#!/bin/sh\nexec "$HOME/.t3/bin/t3" "$@"\n' > ~/.local/bin/t3 && chmod +x ~/.local/bin/t3
3. Start the app and open Settings → About. Per the source, the t3 command row says "Another t3 at ~/.local/bin/t3 runs first in a new terminal. Remove it to use T3 Code's." Next to that is an enabled Install button.
4. Click Install. An error toast appears: "Another t3 at ~/.local/bin/t3 runs first in a new terminal. Remove it, or run the launcher directly at ~/.t3/bin/t3."

Version

0.1.5 (desktop AppImage). The t3 triage CLI was also 0.1.5.

Environment

Arch Linux x64 (kernel 7.2.11), Hyprland, T3 Code desktop AppImage 0.1.5, Node v24.22.1

Evidence

# desktop.trace.ndjson, same trace: getState and cliShim.install succeed, then install fails
desktop.ipc.cliCommand.getState   exit=Success
desktop.cliShim.install           exit=Success
desktop.cliCommand.install        exit=Failure
DesktopCliCommandError: Another t3 at ~/.local/bin/t3 runs first in a new terminal. Remove it, or run the launcher directly at ~/.t3/bin/t3.
    at desktop.cliCommand.install (.../apps/desktop/dist-electron/main.cjs:148586:10)
    at desktop.ipc.cliCommand.install (.../apps/desktop/dist-electron/main.cjs:68862:73)

Related issues

#22361, fixed by #22375, covers the app's own launcher being reported as another t3. This report is a different case: the other t3 really is not the app's link, and #22375 does not change the Settings row.

Fix applied or workaround

Moved the wrapper off PATH and symlinked ~/.local/bin/t3 to ~/.t3/bin/t3, which is what Install creates. t3 --version now prints v0.1.5 from a new shell.

Filed by

Claude Code (Claude Opus 5.5, claude-opus-5-5) via t3 triage