Three reproducible cache failures make PR 5769 unsafe to merge

Connection speed chart

Source: 10 update sequences in Ubuntu WSL 2. Each first connection followed wsl --shutdown; shutdown time is excluded. Payload: 1,222 files, 180.356 MB uncompressed, 45.170 MB compressed. Raw readiness rows; method and ranges.

Decision

Recommended decision: request changes. The speedup can stay, but the cache needs verified identity, repair or fallback after a failed native probe, and lifetime leases that keep pruning away from running backends.

These findings come from the generated scripts in the PR, executed inside Ubuntu on WSL 2 with an isolated HOME under /tmp. The harness removed its fixture afterward. It did not touch the nightly instance, its ports, its database, or ~/.t3/runtime.

Findings

Source: Ubuntu WSL 2, exact generated install and prune scripts from DesktopWslEnvironment.ts, executed 2026-08-20.

1. Verify the archive before assigning its cache identity

DesktopBackendConfiguration.ts lines 526-550 parse the sidecar as 64 hex characters and use it in runtimeId. No code hashes the archive and compares the result. The installer therefore treats the sidecar as a claim, not a check.

# Reproduced result
claimed=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
actual=2ddfa9b013dd5c3b7a7310238c757fc33e68e6ddb46766f3bd5bb27f112e565f
install_exit=0

Source: real sha256sum and the PR's generated install script in Ubuntu WSL 2.

2. Repair or bypass a cache whose native probe fails

DesktopWslEnvironment.ts lines 262-265 call a runtime ready when the marker, server entry, and node-pty/package.json exist. The actual pty.node file is not checked. Later, DesktopBackendConfiguration.ts lines 358-368 turn a failed native probe into a preflight failure. They do not invalidate the staged cache, reinstall once, or fall back to the mounted server tree.

# Reproduced after deleting pty.node and the source archive
second_install_exit=0
ready-marker-present=true
native-payload-present=false

Source: the same installed fixture, then a second execution of the exact generated install script.

3. Keep a lease for the full lifetime of each backend

DesktopWslEnvironment.ts lines 311-340 preserve only the caller's current cache and the newest previous cache. DesktopBackendManager.ts lines 948-956 prune after readiness, but the running process holds no lease that another app instance can observe.

With active A and B plus newer C, A keeps A and C and deletes B. B then keeps B and C and deletes A. A global prune lock would serialize this sequence but would not make it safe. Pruning must skip every runtime with a live usage lease.

What needs to change

Source: review of the exact head plus WSL executions. The lease design uses flock, already required by the install path.

Connection measurements

Ten simulated updates used the PR's generated install script, a 45.170 MB compressed runtime, the Linux node-pty probe, WSL IP discovery, the real server process, and /.well-known/t3/environment as the stop condition. Before every first connection, the harness called wsl --shutdown and selected a new runtime ID. The second and third connections reused that runtime and live VM. Server data persisted across update sequences.

Source: 33 readiness rows. Medians use the average of the fifth and sixth sorted values. Totals start immediately before the Windows-side wsl.exe install invocation and stop at HTTP readiness. Shutdown and teardown are excluded.

The second connection was 4.831 s faster than the cold post-update connection, a 65.5% reduction. The second and third medians differ by 0.004 s, which is noise. A separate no-op control measured WSL boot alone at 4.008 s median across 10 shutdown cycles. That accounts for about 83.0% of the cold-to-warm gap. The remaining difference includes archive extraction and slower cold preflight.

Source: 10 boot-only controls. Each run called wsl --shutdown, then timed wsl.exe -d Ubuntu --exec true. Shutdown duration is excluded.

Scope: this is a shutdown-to-backend-readiness benchmark, not a click-to-render Electron measurement. It exercises the implementation under review with the real server and readiness endpoint.

Verification record

Source: local commands in E:\Projects\t3code-pr-5769-review and GitHub checks for commit f2ce5ce.

bun is not installed in this nightly environment, and this PR declares pnpm@11.10.0. I ran the repository's current pnpm/vp equivalents instead of claiming the unavailable Bun commands passed.

Scope and confidence

high confidence The three blockers reproduced with the implementation under review, not a rewritten approximation. The archive fixture was intentionally small, but it used the same directory shape, tar extraction, marker logic, locking, and pruning functions.

I did not build or install a signed NSIS artifact, time the renderer from an Electron click, or run the full monorepo test suite. I did measure the WSL backend path from a stopped VM through HTTP readiness. The benchmark supports the cache speed claim, but it does not cover corruption or multi-version safety.

Raw evidence

# Archive identity
first_install_exit=0
claimed=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
actual=2ddfa9b013dd5c3b7a7310238c757fc33e68e6ddb46766f3bd5bb27f112e565f

# Cache corruption
second_install_exit=0
ready-marker-present=true
native-payload-present=false

# Cross-version prune
active_runtime_losses=30/30

# Cleanup
isolated_fixture_removed=true

# Exact head
git ls-remote https://github.com/pingdotgg/t3code.git refs/pull/5769/head
# f2ce5cea9d9d799a9d85bda5c5c4a0292cff174a

# Static checks
pnpm fmt:check
pnpm lint
pnpm typecheck

# Targeted tests
pnpm exec vp test run \
  apps/desktop/src/wsl/DesktopWslEnvironment.test.ts \
  apps/desktop/src/backend/DesktopBackendConfiguration.test.ts \
  apps/desktop/src/backend/DesktopBackendManager.test.ts \
  apps/desktop/src/backend/DesktopBackendPool.test.ts \
  scripts/build-desktop-artifact.test.ts

# Shutdown-to-readiness update sequences, n=10 each
first_cold_median=7.373s range=7.178-7.669s
second_warm_median=2.542s range=2.519-2.733s
third_warm_median=2.538s range=2.518-2.556s

# Boot-only control, n=10
wsl_boot_median=4.008s range=3.832-4.285s

# Fixture and cleanup
archive_files=1222
archive_uncompressed=180356009_bytes
archive_compressed=45170403_bytes
readiness_rows=33
benchmark_home_removed=true
wsl_state_after_test=Stopped