Repository navigation
Conversation
… t3 on PATH Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — This focused bug fix ensures generated You can add or adjust custom eligibility rules. Learn more. |
|
Warning Review limit reachedOnly developers with an assigned seat can use this organization's usage-based review budget, and seats here are assigned manually. Ask an admin to assign a seat, or change the review continuation mode in Billing. Next included review available in 33 minutes. View limit details
No actionable comments were generated in the recent review. ℹ️ Recent review info
Walkthrough
Merge Risk:
|
|
Note Written by kept @Gourav224's implementation and regression coverage, merged current main, and resolved the conflict. inlined the realpath comparison into the existing resolver: the final diff is two files, 20 additions and 3 deletions. matching symlinks still use plain verification:
unverified: the native desktop AppArmor error screen, macOS, and native Windows execution. this VM launches sandboxed Chrome successfully, so it does not reproduce that error screen; no before/after UI captures are claimed. CodeRabbit's automatic review was rate limited on this head; its earlier review covered the contributor's original commit. ci: all current-head checks passed or were skipped, including build/typecheck, lint, general tests, all eight server shards, and the final |
Fixes the "wrong
t3in the suggested command" half of #22626. The onboarding step it also asks for is a new-behaviour idea and is not part of this PR.resolveHostCliCommandreturned a baret3whenever anyt3was on PATH, without asking whether it was this install's. On a machine with the desktop app and an older npm global, the AppArmor message told the agent to runsudo env "PATH=$PATH" t3 browser setup, which runs the older install's CLI.When the app names its launcher (
T3CODE_CLI_PATH), at3on PATH now counts as this install's only if it resolves to that launcher, which is true for the link the app installs onto PATH. Any othert3is passed over for the launcher's absolute path. Without a launcher to compare against (npm global, standalone, source) nothing changes.The existing launcher test asserted the old behaviour (an unrelated
t3on PATH wins); it now expects the launcher, and a new case covers a symlink to the launcher staying plaint3. That test fails without the change and passes with it.Two other tests in
invocation.test.ts("requires the npm prefix's bin…", "proves the downloaded executable…") fail on macOS before and after this change because the temp directory sits behind a/varsymlink; I didn't touch them. Not exercised on a real Ubuntu desktop install.🤖 Generated with Claude Code