[Bug]: New sidebar silently stuck on a remote 'No project' scope, so all projects and Working threads appear missing #16692

Activity

1. juliusmarminge commented on Oct 7, 2026

   

   juliusmarminge

   on Oct 7, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Confirmed on main (bfec2387b): a persisted sidebarProjectScopeKey pointing at a remote scratch project can silently filter the new sidebar down to that one “No project” catalog entry, with no strong clear affordance.

   Mechanism (matches the report)

   • Scope is stored per client in localStorage key t3code:ui-state:v1 as sidebarProjectScopeKey (uiStateStore.ts, L30, L157). Load/set only sanitize “non-empty string or null” — no scratch / visibility check (setSidebarProjectScopeKey).
   • Physical/logical keys for non-git projects are ${environmentId}:${normalizedWorkspaceRoot} (derivePhysicalProjectKeyFromPath), which matches the stuck value "<remote-env-id>:/home/<user>/.t3/scratch".
   • Scratch is a real catalog project titled No project, with a dashed chat-bubble icon at create (ManagedProjectFolders.ts, L317-L324). It is included in projectGroups / the scope combobox (unlike the command palette, which strips scratch from normal project rows).
   • While scoped, filterSidebarV2VisibleThreads keeps only threads whose environmentId:projectId is in that group (Sidebar.logic.ts). Working empties; Settled can still show that scratch project’s settled threads — exactly the “everything missing except a couple of Settled rows” shape.
   • Auto-reset only runs when the scoped group is missing from the catalog after snapshots are ready (Sidebar.tsx). A live scratch project never trips that path, so the filter sticks across reloads/nightlies.
   • Active-scope UI is only the header icon swapping to the project favicon (aria-label Filter threads by project: …) (Sidebar.tsx). There is no “Scoped to … · Clear” chip. For scratch, that favicon is the dashed bubble, so it is easy to miss next to Search.
   • Legacy sidebar reads other UI-store prefs but not sidebarProjectScopeKey, so it shows everything; other clients are unaffected because the key is local.

   How the key gets set (picker or thread context “filter by project”) is plausible; v1→v2 localStorage import could also carry an existing t3code:ui-state:v1 value. We did not need to pin the exact entry path — once set, persistence + missing clear UI are enough to explain days of breakage.

   Related (different)

   • #14260 — similar “only Settled visible” symptom; closed needs more info around DB/render, not project scope.
   • #12113 — open UX PR to distinguish the unscoped filter icon from “new project”; does not validate/reset scratch scopes or add a clear chip.
   • #14165 / #14997 — scoped new-chat and environment filter features; not this stuck-filter bug.
   • Merged #9416 — moved the filter into persisted UI state (why a bad key survives Settings/restarts). No open PR found that fixes silent scratch scope.

   Workaround (as reported) — null sidebarProjectScopeKey and reload, or use the legacy sidebar. Opening the scope combobox and choosing All projects should also clear it when the picker is reachable.

   Next step

   Treat as a product bug in the new sidebar scope control:

   1. Show an obvious active-scope indicator (e.g. “Scoped to No project · Clear”) whenever sidebarProjectScopeKey !== null, not only an icon swap.
   2. On load / when snapshots are ready, validate the key: if it resolves to a scratch project (isScratchProject / scratchWorkspaceRoot) or to a group the user cannot reasonably discover, reset to null (or at least refuse to keep scratch as a sticky scope).
   3. Optionally keep scratch out of the scope combobox the same way the command palette keeps it off the normal project list, while still allowing an explicit temporary filter with a clear exit.

   Thanks for the localStorage dump and the legacy-vs-new comparison — that made the root cause easy to confirm on main.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 7, 2026
3. cursor

   added a commit that references this issue on Oct 8, 2026

   Add captures for pingdotgg#16692

   47e8656
4. paulomoguerra commented on Oct 8, 2026

   

   paulomoguerra

   on Oct 8, 2026

   More actions

   Same root cause here, but the stuck scope was a regular local project, not a scratch one.

   • 0.0.46-nightly.20261008.2819, macOS 27, Apple Silicon.
   • New sidebar: no projects, empty Working shelf, only "Settled (22)". The server was healthy: t3_thread_list returned active threads in every project.
   • The only sign of the filter was a two-letter badge ("CK", the project's initials) next to Search, in place of the filter icon. I didn't recognize it as an active filter and don't know how it got set.
   • The scoped project had no active threads, so the sidebar looked like everything was gone.
   • Sidebar (legacy) showed everything. Turning legacy off, opening the badge and choosing All projects fixed it (Settled went from 22 to 246).

   So point 2 (resetting scratch scopes) wouldn't cover this case: any scope on a project with no active threads looks like data loss. The visible "Scoped to · Clear" chip from point 1 would have caught it.