Skip to content

[Bug]: Opening a link to a thread created since the web client's last visit redirects to an unrelated thread #14689

Open
#14697
Open
[Bug]: Opening a link to a thread created since the web client's last visit redirects to an unrelated thread#14689
#14697
Labels
bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

Description

@saphid
saphid
opened on Oct 2, 2026

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

  1. Open the web client on an environment and view any thread, so the browser caches that environment's shell.
  2. Close the tab (or navigate away) so this client stops receiving live updates.
  3. Create a new thread in that environment somewhere else (another device or client, the CLI, or an agent).
  4. In the first browser, open a full-page link straight to the new thread: /<environmentId>/<newThreadId>.

In my run, step 3 used the server's HTTP dispatch endpoint (thread.create), and steps 1, 2 and 4 used headless Chromium. Everything ran against an isolated local server with synthetic data, and the server and browser talked directly, with no transport manipulation.

Expected behavior

The link opens the new thread, which exists on the server, or at least waits until the client knows whether it exists.

Question for triage: what is the intended behavior while a client is still synchronizing? Should a thread link wait until the shell is live before it is treated as missing, and should already-available thread content be shown meanwhile?

Actual behavior

The client redirects to / and lands on an unrelated thread (the environment's New thread). It stays there after synchronization finishes, even though the target thread appears in the sidebar by then.

Measured in the run below: about 0.2 s after loading, the app is still on its splash screen at the target path. By 3.1 s the path has changed to an unrelated thread's, and it is unchanged at 8.1 s.

Likely cause, from source on main: apps/web/src/components/ThreadRouteView.tsx treats the route as bootstrapped as soon as any shell snapshot exists (bootstrapComplete = shell.data?.snapshot._tag === "Some", line 85 at 094fb230), and that includes a cached snapshot that predates the thread. With no detail loaded yet, the thread resolves as missing, and the effect navigates to /.

Impact

Minor bug or occasional failure

A link to a thread created since the client's last visit (from another device, a notification, or an agent) opens the wrong thread, and the user has to find the right one manually.

Version or commit

The web client was built from pingdotgg/t3code@35be904. ThreadRouteView.tsx and threadRoutes.ts are unchanged from there through current main 094fb230. The server was the same source, run with node apps/server/src/bin.ts --mode web.

Environment

macOS (Darwin 25.5, arm64), Node 24.12.0, headless Chromium (chromium-headless-shell 153.0.8010.12) at 1280×800. Only the web client was checked; desktop and mobile were not. The "Codex update available" toast in the captures comes from the test server probing the locally installed Codex CLI, and is unrelated.

Screenshots, recordings, or supporting files

Base 35be904: the link to Created elsewhere A lands on workspace / New thread (real time; GIF sampled at 10 fps, no cuts or speed changes):

Base 35be904: link to a newly created thread lands on an unrelated New thread

Full MP4 · Screenshot 3 s after loading

For comparison: the same steps with the closed candidate fix from #10604 (1cd6689)

The link to Created elsewhere B stays on that thread. This only illustrates one possible intended behavior; it is not a request to merge that PR.

Candidate 1cd6689: link stays on the newly created thread

Screenshot 3 s after loading

Related, but not duplicates: #11502 (mobile now waits for thread deep-link hydration) and #10888 (iOS "Thread unavailable").

Activity

  1. juliusmarminge commented on Oct 2, 2026

    @juliusmarminge
    juliusmarminge
    on Oct 2, 2026
    Member

    Note

    Grok responding on behalf of Julius.

    Triage

    Thanks for the careful repro and the timed captures, @saphid! This is a real web bug, and it's still present on current main (a3abb52660). ThreadRouteView.tsx and threadRoutes.ts still match the lines you cited.

    To answer your question: a thread link should wait until that environment's shell is live before deciding the thread is missing. While it waits, any content that's already loaded should stay on screen.

    What happens today

    bootstrapComplete is shell.data?.snapshot._tag === "Some", so any snapshot counts, including the cache saved from your last visit. The shell does report its own status (empty, cached, synchronizing, or live in packages/client-runtime/src/state/shell.ts), and on a warm start it stays synchronizing until the new session gets a fresh snapshot. The route never checks that status.

    resolveThreadRouteRenderState reports the thread as missing once that check passes and the thread isn't in the snapshot, unless thread detail or a local draft has already loaded. The route then replaces the URL with /. IndexDraftLanding starts a draft on the most recently active project, which is the unrelated New thread in your capture. allEnvironmentShellsBootstrappedAtom also treats any snapshot as enough, so that draft can come from the same stale cache. Once the URL has been replaced, the live snapshot that arrives later has no way to send you back. The thread only shows up in the sidebar.

    Intended behavior

    • While the shell is cached or synchronizing, stay on /<environmentId>/<threadId> and don't redirect to /.
    • If thread detail or a local draft for that link has already loaded, show it while waiting. Otherwise keep the existing loading state.
    • Once the shell is live, the current redirect is correct: if the thread is still missing or marked deleted, leave the route.
    • A sync error doesn't prove the thread is gone, so the app shouldn't open a new thread from the stale cache. Mobile already handles this in thread-route-hydration.ts: it keeps waiting while the shell is synchronizing and only gives up on shellHasError or deleted.

    Web already follows the same rule elsewhere. createAllEnvironmentProjectSnapshotsReadyAtom ignores cached and synchronizing snapshots before it decides a saved project no longer exists.

    Desktop uses this same web route, so it should have the same bug. Mobile doesn't, thanks to its deep-link gate.

    Related

  2. juliusmarminge
    added
    bugSomething is broken or behaving incorrectly.
    via-triageFiled through npx t3 triage
    on Oct 2, 2026
  3. saphid
    added a commit that references this issue on Oct 3, 2026

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

    4ed3c22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions