Repository navigation
Conversation
pingdotgg#29684 and pingdotgg#30480 made three of the hints `t3 up --base-dir <dir>` prints carry the flag. The rest still named bare commands that run against the default ~/.t3 home: "Run `t3` to use T3 Code here." after turning remote access off with no service, and, in the setup summary `t3 status` shares, "Run `t3 connect`." for a revoked link, "Turn it off: `t3 up --no-lan`." for the old LAN default, and `t3 status`'s own "Change access: `t3 up`." Every hint now comes from one resolveHints call that runs each command through resolveHostCliCommand with the caller's --base-dir, so the setup summary and next steps name the same home and launcher as the pairing hint. resolveHostCliCommand trims the empty subcommand that names the root `t3` command. Bug: t3 up and t3 status hints drop --base-dir
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — Setup and status hints now preserve the selected base directory and launcher, reducing the chance of follow-up commands targeting another installation. Service behavior, access defaults, and JSON status output remain unchanged. You can add or adjust custom eligibility rules. Learn more. |
|
No actionable comments were generated in the recent review. Walkthrough
Merge Risk:
|
Problem
t3 up --base-dir <dir>andt3 status --base-dir <dir>still print four hints that drop--base-dir: "Runt3to use T3 Code here.", "Runt3 connect." for a revoked link, "Turn it off:t3 up --no-lan." for the old LAN default, andt3 status's "Change access:t3 up." Each bare command runs against the default~/.t3home, not the one you asked about.To see it on a Linux machine with no T3 Code service installed:
Change
In
apps/server/src/cli/up.ts, a newresolveHintsresolves every command these hints name once, throughresolveHostCliCommandwith the caller's--base-dir.formatSetup(shared byt3 upandt3 status) andformatNextStepstake that result instead of hard-coding baret3commands. The pairing hint (#29684) and the retry hint (#30480) now read from the same object. The retry hint is now resolved up front with the rest rather than only on the branch that prints it, sincet3 statusneeds the sameupcommand. The serve andservice restarthints still resolve on the branch that prints them.With the fix the hints read
t3 --base-dir <dir>,t3 connect --base-dir <dir>,t3 up --base-dir <dir> --no-lanandt3 up --base-dir <dir>. The root command andt3 connectboth take--base-dir. Like the other resolved hints, they also print the runner form (npx t3@… up) or this install's launcher when that is how the CLI ran. Run as plaint3with no--base-dir, the text is unchanged.t3 status --jsonprints no hints and skips the lookup.resolveHostCliCommandbuildst3 <subcommand>, so the empty subcommand for the root command used to leave a trailing space (t3/t3 --base-dir …). Inapps/server/src/cli/invocation.tsit now trims that before joining the arguments.Scope and approval
This is the follow-up #30480 ("t3 up's retry and restart hints keep --base-dir") named and left out. Its body says: "Three bare hints that
t3 up --base-dircan still print are left for a follow-up, because two of them come fromformatSetup, whicht3 statusshares: "Runt3 connect.", "t3 up --no-lan" and "Runt3to use T3 Code here."" #29684 fixed the pairing hint the same way.t3 status's "Change access:t3 up." is the same defect in the same output, so it is included.It is a small, focused fix for an obvious bug: printed hints only, with no contract, setting or other behaviour change. No open PR changes these hints. #23878 edits nearby lines in
up.tsfor a different problem (a service that belongs to another home). #25417 editsinvocation.tsbut not this function's argument join.Verification
Two cases in
apps/server/src/cli/up.test.ts. The existing table rowa route turns off with no service to runalready runst3 up --base-dir <baseDir> --no-lanand now also checks its last hint. A newt3 status names commands that keep --base-dircase runst3 status --base-dir <baseDir>against an installed service with an emptyservice.env(the old LAN default) and checks the "Turn it off" note and the "Change access" line. The revoked-link hint has no case of its own: it needs a T3 Connect build config and a revoked-link secret, which this table does not set up. It readshints.connectfrom the sameresolveHintscall.On
mainwith only the test commit,vp test run src/cli/up.test.ts(fromapps/server):With the fix:
Tests 23 passed (23).These runs were on Windows with two uncommitted test edits that make it behave like CI: the platform set to
linuxand the tempbaseDirwritten with forward slashes. Without them, the #29684 and #30480 rows already fail onmain, becauseresolveHostCliCommandquotes each word for PowerShell, and the two cases here fail the same way. On Windows the fixed output isChange access: `t3 up "--base-dir" "C:\…\t3-status-test-6MAeri"`., so the flag does reach the hint there too. CI runs the server tests on Ubuntu.vp run check:changed: format, lint, knip, graphql and typecheck pass. Its test step fails only on the Windows quoting rows above and on twoinvocation.test.tscases (npm-global launcher detection) that also fail onmainon Windows.A real
t3 status --base-dirrun from the source CLI, on Windows with no T3 Code service installed, before and after (it only reads state):On Windows the command prints in this machine's PowerShell launcher form, as the pairing hint already does.
Not checked: a real
t3 uprun, which would replace this machine's service, and the revoked-link hint in a T3 Connect build.Bug: t3 up and t3 status hints drop --base-dir
This was written with Claude Opus 5.5 in Claude Code, driven from T3 Code.