Repository navigation
fix: fork installs update from the fork again and carried upstream PRs are tracked - #23
Conversation
…s are tracked An upstream sync reverted the CLI release repo to pingdotgg/t3code, so `t3 update` on a fork install pointed at upstream releases. The fork's repo now lives in @t3tools/shared/fork, with a test that also pins the installer literals. Upstream PRs the fork carries are listed in .github/fork/carried-prs.json with the head we took. scripts/fork-carried-prs.ts reports new commits, merges and closes, and a weekly workflow runs it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
github-actions
Bot
added
vouch:trusted
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fc237bd95e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| import { compareSemverVersions } from "./semver.ts"; | ||
|
|
||
| const CLI_RELEASE_REPOSITORY = "pingdotgg/t3code"; | ||
| const CLI_RELEASE_REPOSITORY = FORK_REPOSITORY; |
There was a problem hiding this comment.
When Settings → About switches a boot-service environment to another update track, UpdateTrackSwitchDialog still resolves the target through npmReleaseAtom, backed by cloud/npmRelease.ts querying upstream's t3 npm package. However, cloud/selfUpdate.ts installs that exact version through pinnedRuntime.ts, whose download URL now defaults to the fork because of this change. The fork's fork-release.yml publishes independently versioned nightlies, not upstream's stable releases, so switching to Stable now attempts to download an upstream version from the fork and fails instead of updating. Make track-switch resolution and archive downloads use a consistent release source, or explicitly disable unsupported tracks.
AGENTS.md reference: AGENTS.md:L69-L69
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Confirmed, but the bug predates this PR. The track switch reads its target version from upstream's t3 npm package, and the fork doesn't publish to npm. Before this PR, the switch installed upstream's archive of that version, which quietly moved a fork install onto an upstream build running on a database with fork migrations. Now the download from fork releases fails instead, which is the safer of the two. The fork also has no Stable releases, only nightlies.
The real fix depends on what the fork does about npm (npx t3, and whether to publish or disable tracks it doesn't ship). A follow-up already owns that, so I'm leaving this PR's scope as is.
 [Medium impact] The PR appears safe to merge; no actionable issues were found. SummaryThis PR restores the fork as the source for CLI updates and centralizes its release links.
Reviews (1) · Last reviewed commit: "fix: fork installs update from the fork ..." · Reviewed by Greptile |
#24) [skip ci] ## Why The fork publishes only nightly builds, but its install docs, install script headers, and the desktop update-track switch still sent fork users to upstream installs, upstream releases, or a stable channel the fork doesn't have. #23 moved the release source to the fork. This covers what it left. ## What changed - `install.sh` and `install.ps1` headers give the fork's raw script URL with `T3CODE_CHANNEL=nightly`. Their errors no longer point at `t3.codes/download` or `npm install -g t3`. `README.md` and `docs/user/install.md` link the fork's releases, label package managers as installing upstream, and say the fork ships Linux x86_64 only. - `FORK_HAS_UPDATE_TRACKS = false` in `@t3tools/shared/fork` hides the desktop update-track switch and its settings search entry. The switch took its target from upstream's npm `t3`, which fork releases don't have. `docs/user/updating.md` explains this. - `fork.test.ts` fails if the README, install guide, or scripts mention `t3.codes/install`, `t3.codes/download`, a bare `t3.codes` link, or upstream's releases page. ## Scope - Covers docs, install scripts, and the update-track switch. - Leaves about 10 in-app `npx t3 …` strings, plus `updating.md`'s `npx t3@<client-version>` line, pointing at upstream npm. Fixing them means rewording shared upstream UI, so they need their own change. - Fork desktop users who once chose Stable have no in-app way back. That comes from reading the code and wasn't reproduced. ## Tradeoffs - `npx t3` still runs upstream, and the docs now say so. Publishing a fork npm package needs the maintainer's OK. ## Blast Radius Docs and scripts change for fork users only. Hiding the switch also hides its "machines on the other track" review path for connected remote machines. ## Verification - `scripts/install.sh`, run as its header says in an isolated home, installed `0.1.8-nightly.20261106.100`, and `t3 --version` reported it. Without `T3CODE_CHANNEL` it stops with "could not find a stable release". - `vp run check:changed fork/main` passes, and `fork.test.ts` passes 9 of 9. - Not run: the PowerShell one-liner (no Windows machine), and `install.sh` on Linux arm64, where it should fail with "no release archive" because the fork publishes none. Model and harness: Claude Opus 5.5 (implementation, update onto main, review) via Claude Code in T3 Code.
An upstream sync reverted the CLI release repo to
pingdotgg/t3code, sot3 updateon a fork install pulled upstream's releases. Separately, upstream PRs we merge early are never re-checked, and four of them have moved on since we took them.Fork release source
@t3tools/shared/forkholds the fork repo slug.cliRelease, the desktop update link and startup recovery read it.fork.test.tsfails if a sync reverts it, and pins therepo=literals ininstall.shandinstall.ps1.SHA256SUMS, sot3 updateresolves against it.Carried upstream PRs
.github/fork/carried-prs.jsonlists each carried PR and the head we took.scripts/fork-carried-prs.tsreportsunchanged,new-commits,mergedorclosed-unmerged. Entries markedclosedUpstreamstay quiet until their head moves.fork-carried-prs.ymlruns it weekly and on dispatch.vp run check:changedpasses. The weekly workflow has not run on GitHub yet.🤖 Generated with Claude Code
Need help on this PR? Tag
@codesmith-botwith what you need.