fix(web): keep thread links open until the shell is live

[saphid]

Problem

Opening a link to a thread created since the web client's last visit (from another device, the CLI, or an agent) lands on an unrelated New thread. It stays there even after the thread appears in the sidebar. The route treated any shell snapshot as authoritative, including the cache saved from the last visit, so the thread read as missing and the route replaced the URL with / (#14689). Desktop uses the same route.

Change

ThreadRouteView now decides a thread is missing only once the environment shell's status is live, instead of as soon as any snapshot exists. resolveThreadRouteRenderState reports ready when thread detail or a local draft has already loaded, before it checks whether the shell is live. So:

• While the shell is cached or synchronizing, the link stays on /<environmentId>/<threadId>. Already-loaded content is shown; otherwise the existing loading state remains.
• Once the shell is live, a thread that is still missing or marked deleted leaves the route through the existing redirect.
• A sync error leaves the shell non-live, so it no longer redirects to a stale-cache thread.

The shell synchronization in packages/client-runtime is unchanged. Mobile already waits for hydration and isn't affected.

Scope and approval

Fixes #14689, the triaged bug, labelled bug and via-triage. The maintainer triage set the intended behavior this follows. It replaces #10604, which addressed the same web behavior but was closed for missing verification; GitHub didn't allow reopening it. This version is narrower: it drops #10604's change to legacy shell resubscription, which this fix doesn't need.

Behavior left as it is on main: a missing link in an environment with no threads still doesn't redirect once the shell is live, and a local draft still takes precedence over a confirmed deletion.

Verification

Focused tests: apps/web vp test run src/threadRoutes.test.ts, 16 passed. The new cases:

• cached and synchronizing shells aren't authoritative;
• loaded detail or a draft renders while the shell is cached or synchronizing;
• a deleted thread waits for the live shell before redirecting.

Targeted lint, format, and the @t3tools/web typecheck passed.

Reproduction (the #14689 scenario), run the same way on main b33eda1 and on this branch:

1. Open the web client and view a thread, so the browser caches the shell.
2. Close it.
3. Create a thread elsewhere (HTTP dispatch thread.create).
4. Open a full-page link to the new thread.
5. About 8 s later, drop the client's socket so it reconnects.

Environment: headless Chromium 153 (chromium-headless-shell), 1280×800, macOS arm64, Node 24.12.0. An isolated local server ran with synthetic data, started from source with node apps/server/src/bin.ts --mode web; this change doesn't touch server code. A small local proxy served each web build and passed traffic through unchanged; its only intervention was closing the sockets for step 5. T3's Browser panel was unavailable here ("No preview automation host is available"), so the capture was scripted. Recordings are real time, with no cuts or speed changes; GIFs are sampled at 10 fps. The "Codex update available" toast comes from the test server probing a local Codex CLI. The reconnect banner shows the test server's environment name.

Before (main b33eda1): the link to Created elsewhere (main) is replaced by workspace / New thread by 3.1 s. It stays there after the shell is live and after reconnecting, while the target sits at the top of the sidebar.

MP4 · Screenshot once the shell is live

Enlarged header once the shell is live (cropped from that screenshot):

After (this branch): the link to Created elsewhere (fix) shows that thread by 3.1 s, keeps it once the shell is live (selected in the sidebar), and keeps it through the socket drop and reconnect.

MP4 · Screenshot once the shell is live · Screenshot while reconnecting · Capture receipt

Enlarged header once the shell is live (cropped from that screenshot):

Not checked: the desktop app (it uses the same route), sync-error and deleted-thread paths in a real client (covered by the focused tests only), and relay/tunnel connections.

Original fix (#10604): GPT-5.6 Sol and GPT-6 Astra in the Codex harness. This narrowed fix, tests and evidence: Claude Opus 5.5 in Claude Code via T3 Code; browser capture driven by GPT-6 Astra; independent review by GPT-6.1 Sol (Codex harness via T3 Code).

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at 4ed3c22

Macroscope's review found this PR approvable — This is a narrowly scoped, well-tested web bug fix that prevents stale or incomplete shell snapshots from redirecting valid thread links. Existing redirect behavior remains intact after the shell becomes live, with no schema, infrastructure, security, billing, or static-analysis changes.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository: pingdotgg/t3code/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 0d3c7560-ada7-4160-9949-0354f69723ad

📥 Commits

Reviewing files that changed from the base of the PR and between 38d9384 and 4ed3c22.

📒 Files selected for processing (3)

• apps/web/src/components/ThreadRouteView.tsx
• apps/web/src/threadRoutes.test.ts
• apps/web/src/threadRoutes.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 6 remain after this review.

---

📝 Walkthrough

Walkthrough

Thread route readiness now uses snapshot status to determine bootstrap completion. Available server-thread details and local drafts can render as ready while the shell snapshot is cached or synchronizing.

Changes

Thread route readiness

Layer / File(s)	Summary
Snapshot authority and render state apps/web/src/threadRoutes.ts, apps/web/src/threadRoutes.test.ts	A new helper treats only live snapshots as authoritative. The resolver returns ready when server-thread details or a local draft exist, and tests cover snapshot statuses and render states.
Route bootstrap integration apps/web/src/components/ThreadRouteView.tsx, apps/web/src/threadRoutes.test.ts	ThreadRouteView uses snapshot authority to determine bootstrap completion. A test verifies that a deleted thread with no detail remains loading while its snapshot is cached.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Low

Suggested reviewers: juliusmarminge

Merge Risk: ⚪ Minimal · up to 4ed3c

Missing-thread redirects now wait for initial shell catch-up, reducing redirects caused by stale cached snapshots. No material merge risk introduced by this change remains.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 4ed3c

The change preserves environment-specific thread identity and avoids redirects based on stale data. No authorization bypass was established, but cached deleted-thread behavior and file cleanup during failed synchronization remain partly unverified.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The demonstrated client-side scope is the route-selected environment/thread, its local draft state, and queued file objects. Thread identifiers remain paired with environment identifiers; inspected file consumption and removal use field-wise scoped-reference equality. Broader tenant, service, or credential exposure was not established.

Trust Boundaries and Controls

• observed — ChatView reconstructs a scoped reference from route identifiers and independently derives thread-detail loading state. Representative actions retain loading and environment-availability gates. These controls counter an assumption that route readiness alone grants command authority, but complete enforcement for cached deleted-thread actions remains unverified.

Resilience and Maintainability Implications

• inferred — A queued drop that lands on a target lacking usable thread state can remain unresolved while synchronization never becomes live. Failed navigation removes its individual drop, ChatView consumes matching drops when an active thread exists, and recovery to live triggers missing-target cleanup. An independent abandonment or unmount cleanup owner was not established; the supported uncertainty concerns local file-state ownership, not demonstrated cross-thread disclosure.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 25.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 3 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: thread links remain open until the shell is live.
Description check	✅ Passed	The description covers the problem, change, scope and approval, and focused verification. It also identifies untested paths and includes UI evidence.
Linked Issues check	✅ Passed	Issue #14689 asks the web route to wait until the shell can confirm whether a linked thread exists. ThreadRouteView now treats only a live shell as authoritative. resolveThreadRouteRenderState k…
Out of Scope Changes check	✅ Passed	The whole-PR change summary identifies updates to ThreadRouteView.tsx, threadRoutes.ts, and threadRoutes.test.ts. The implementation and focused tests support issue #14689. No unrelated changes …

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

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

Autopilot is currently an internal CodeRabbit preview.

---

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

Dismissing prior approval to re-evaluate 38d9384

Dismissing prior approval to re-evaluate 4ed3c22

[saphid]

Review requested

Date (UTC)	Reviewer	Where
2026-10-06	Maria	Discord DM

_{Logged so this PR shows when a maintainer was asked to review it.}

[maria-rcks]

Note

Written by claude-opus-5-5 on behalf of Maria

Hi! We are cleaning up open PRs, and this one appears to have been created with an older model (gpt-5.6-sol). If this change is really important, we recommend rebuilding the PR with a newer model if possible.

[maria-rcks]

Note

Written by claude-opus-5-5 on behalf of Maria

Reopening, this was closed by mistake. Sorry for the noise!