[only21mil]

Problem

Two T3 servers can share one home directory, for example a background service on an older release and a newer t3 started by hand. They also share the headless shell install root, tools/chrome-headless-shell/<platform>/.

When the newer server installs its pinned headless shell, PreviewBrowser.install deletes every other entry in that root except staging directories from the last hour. The older server's version goes with them. That server's next executable call finds nothing, downloads its own version again (about 120 MB), and that install deletes the newer server's version. Each server then breaks the other in turn.

The comment above that cleanup already says two servers can share a home and protects their staging directories, so this case is expected. Only installed versions were missing the same care.

Change

apps/server/src/preview/PreviewBrowser.ts: after an install, cleanup keeps the newest other version directory as well as the current one, and removes everything older as before. Order is numeric (localeCompare with numeric: true), so 0.10.0 sorts above 0.9.0. Dot-prefixed names are skipped, so a staging directory never counts as the previous version. Staging directories keep their one-hour rule.

This follows pruneTools in apps/server/src/device/deviceToolMaintenance.ts, which keeps "the last other successful install" for device tools for the same reason. Disk use stays bounded at two versions.

I kept it to the simplest rule. Detecting which version another server is running would need a cross-process marker or a process scan, which is more than this bug needs.

Scope and approval

No issue. This is a small, focused fix for a bug the code already describes: the cleanup comment names the shared-home case, and the deletion contradicts it. The diff is 6 added and 2 removed lines in the source, 3 added and 1 removed in the existing test.

Verification

The existing test installs a verified download with its file modes and then reuses it already seeds an old version and checks the directory listing after install. I changed the seed from 1.0.0 to 0.9.0 and 0.10.0, and the expected listing now keeps 0.10.0 and drops 0.9.0. That pins both the kept version and numeric order.

cd apps/server && pnpm exec vp test run --config ../../vite.config.ts --dir . src/preview/PreviewBrowser.test.ts

• Main plus the test change only: 1 failed, 6 passed. The received listing is missing "0.10.0".
• This branch: 7 passed.

The regression test failing on main and passing on this branch:

To check the two-server case itself, I ran a throwaway test (not part of this PR) that creates two PreviewBrowser services on one home: an older one pinned to 1.0.0 installs first, then a newer one pinned to 1.2.3. On main, only 1.2.3 is left and the older service reports installed as None. On this branch, both versions stay and the older service still reports its executable.

Also run on this branch: vp lint and vp fmt --check on both changed files (clean) and pnpm run typecheck in apps/server (exit 0).

This is server-only. No screen changes: the preview panel shows the same browser, and the only difference is which old directories survive on disk.

Not checked:

• Two real T3 releases with different pinned headless shells running against one home. The pin has not changed since feat(preview): run the browser on the environment server #15328, so no such pair of releases exists yet; the throwaway test stands in for it.
• Windows. The focused test ran on macOS (arm64) and the two-server test on Linux (x64). The change only affects which names go to fs.remove.
• Three or more servers on different versions sharing a home, and a server pinned more than one
  version behind. Only the newest other version is kept, so a version other than the newest one can
  still be removed and downloaded again.

Prior PRs

None found for this cleanup. It was added in #15328 by @maria-rcks.

Production fix, tests, PR description and images written with Claude Opus 5.5 in T3 Code Nightly.

🤖 Generated with Claude Opus 5.5 in T3 Code Nightly

[coderabbitai]

Warning

Review limit reached

Only 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 34 seconds.

Check out review usage here.

View limit details

Limit details: You’ve used all 10 included reviews currently available.

Learn how review limits work.

Review configuration:

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: d487078
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: f37d6656-447e-469e-a077-7d487cf45d5b

Commits

Reviewing files that changed from the base of the PR and between d487078 and 6aa712f.

Files selected for processing: 2

• apps/server/src/preview/PreviewBrowser.test.ts
• apps/server/src/preview/PreviewBrowser.ts

Finishing Touches: 💡 1

🛠️ Fix failing CI checks: 💡

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

@only21mil, your retention rule addresses the two-version shared-home churn without adding cross-process state. I kept your commits and implementation, merged current main, shortened the cleanup comment, and extended the existing install test to cover both upgrade and downgrade order. No production behavior was dropped. The final diff is two files, 15 additions and 11 deletions.

Verification on 6aa712f4186b6b81571d09729b6c25368c193468:

• Reproduced on current main d487078f: the regression failed because 0.10.0 was deleted (six other cases passed).
• Blacksmith: all eight focused tests passed; vp run check:changed passed formatting, lint, both knip checks, GraphQL validation, scripts/server typechecks, and focused tests.
• Two independent source reviews found no actionable issues.

Unverified: two actual T3 releases sharing a home and Windows runtime behavior. The filesystem test exercises the real installer with a verified fixture download; it does not launch Chrome. Three or more pinned versions remain outside this bounded two-version policy. No UI changed, so no screenshot evidence applies. GitHub CI passed on this head, including all eight server test shards and build/typecheck. GitHub reports CLEAN/MERGEABLE. CodeRabbit passed its check but was rate limited, so no bot source review was available; both independent source reviews found no actionable issues.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

verified as-is on exact head 6aa712f4186b6b81571d09729b6c25368c193468, on this task's linux x64 boat vm. no source changes or pushes.

• reproduced on github/main (f120c51134) in /home/user/main, after vp i. installed a genuine second chrome for testing distribution (156.0.8078.73) in the isolated browser root. created a project through the web ui, selected codex gpt-6.1-sol through the local proxy, and sent a real provider turn calling preview_open. the real installer downloaded and installed its pinned 156.0.8078.70, then deleted 156.0.8078.73.
• stopped main by its captured process group before starting this exact pr head, after vp i, with vp run dev --no-seed --home-dir /home/user/t3code/.t3 (server 13773, web 5733). repeated the same genuine second-browser installation and web/composer/provider flow. this time both versions survived. the pinned browser opened and preview_snapshot confirmed the dev app's pairing page. the retained browser also launched and rendered that page through playwright.
• exercised the preview in the real web client using repo playwright and /usr/bin/google-chrome: took control, entered /pair?verification=23771, navigated, and clicked back. a second real codex turn closed the first tab, opened and inspected another, then closed it. both browser executables retained the same inode, size and modification time, confirming reuse without replacement.
• blacksmith: vp test run apps/server/src/preview/PreviewBrowser.test.ts passed all 8 cases. existing ci reports 27 successful checks on this head. the task's blacksmith worker is stopped.

short filesystem transcript:

main before preview_open: 156.0.8078.73
main after preview_open:  156.0.8078.70
pr before preview_open:   156.0.8078.73
pr after preview_open:    156.0.8078.70  156.0.8078.73
pinned executable:       Google Chrome for Testing 156.0.8078.70
retained executable:     Google Chrome for Testing 156.0.8078.73
second provider open:    pairing page rendered; executables unchanged

command transcript

Not verified

• two concurrent released t3 servers with different pins sharing one home. main and this head pin the same version, and this pass ran one dev server at a time. the second browser was a manually extracted genuine google distribution, not a fixture or fake executable. the real provider/client installer path demonstrated the deletion and retention difference, but this is not proof of concurrent two-release operation.
• macos/windows, native mobile, relay/tunnel, and three or more active pinned versions were not exercised here.
• initial main navigation to 127.0.0.1:8693 failed because vite listened on ipv6 localhost; localhost:8693 rendered successfully. the pr's first call returned installation progress and its retry succeeded. provider transport also retried during that turn; nothing stalled for ten minutes.
• separate nearby ui observation, left unchanged: the floating preview canvas intercepted a pointer click on its dock button. keyboard focus plus enter docked it, and right-panel navigation worked. this is outside the two-file installer diff.