Repository navigation
[Bug]: Empty thread details card shows on the new thread screen when no project is chosen #25362
Description
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
- Start T3 Code with no projects added (fresh userdata), New design on (default since nightly 20261026.3710)
- Land on the new thread screen ("Choose a project to start")
- Use a window wide enough for the inline thread details card
Expected behavior
No thread details card while it has nothing to show, or the card appears only once a project is chosen
Actual behavior
An empty rounded card sits at the top right under the window controls. The card opens inline by default (DEFAULT_THREAD_PANEL_VISIBILITY.inlineOpen: true in rightPanelStore.ts), but with no project every section renders nothing: BranchToolbar returns null without an active project, shouldShowOpenInPicker is false, there are no scripts and no gitCwd, and automations and relationships are skipped for drafts. Only the card frame is drawn
Related: the device chip under the composer is also missing in this state because shouldShowComposerContextStrip requires an active project, so there is no way to pick which device "start without a project" uses before it starts (it uses the primary environment)
Impact
Cosmetic issue
Version or commit
0.1.3-nightly.20261026.3710 (f40c7c6)
Environment
Windows 11 Pro 10.0.26200, T3 Code desktop (Nightly)
Logs or stack traces
Screenshots, recordings, or supporting files
Workaround
Choose a project or "start without a project", or close the card with the thread details toggle in the header
Activity
juliusmarminge commentedon Oct 26, 2026
Tested the web client on current main bfc7177f9f, with a fresh isolated home, automatic project creation disabled, New design enabled, and a 1920×1080 viewport. With no projects, startup shows “What should we work on?” and no thread details card. Starting without a project opens a draft with populated workspace controls.
What navigation or shortcut takes you from the fresh workspace to “Choose a project to start” before choosing a project or starting without one? Is there a saved draft or restored window involved?
Neonsy commentedon Oct 26, 2026
@juliusmarminge Found it. It's a stale client cache, not a fresh install. The empty card is real, but it needs a project that was deleted while the app was closed,
and #20183 made that reachableMy setup: I run a personal PowerShell scrubber that wipes local T3 Code thread data while the app is closed. It empties
statev2.sqlitein place, which also removes all projects, and it deletes logs, attachments, scratch folders and rebuildable caches. It keeps settings, sign-ins, paired devices and the renderer profile's Local Storage and IndexedDB, because IndexedDB also holds the cloud relay proof key. So "fresh userdata" in my report was wrong. The server was empty, but the client's cached shell still listed my old projectsWhat happens: On startup,
IndexDraftLandingin_chat.index.tsxpicks the most recent project from the cached shell and opens a draft for it.Before #20183 that pick waited forWhen the live shell arrives without that project, the draft's project no longer resolves, so the headline falls back to "Choose a project to start" and the inline thread details card renders with every section emptybootstrapped. Now it runs on cached data.Repro without my scrubber (web mode, nightly 20261026.3710):
statev2.sqlite/Control: Same steps, but delete the
t3code:connection-runtimeIndexedDB database before step 3 and keep all Local Storage. Startup opens a draft for the live project with a filled cardSuggestion: Only start the landing draft from environments whose shell is live. That keeps the point of #20183 for other environments.
Hiding the card when every section is empty would also stop the empty frameEdit: Struck parts are wrong or outdated. See the correction and narrower suggestion below
Note
Approved by the author, posted by Claude Opus 5.5
Neonsy commentedon Oct 26, 2026
@juliusmarminge Correction to my comment above: #20183 is probably not the cause. The
bootstrappedgate it removed already counted a cached shell snapshot as ready.allEnvironmentShellsBootstrappedAtomskips any environment whose snapshot is set, and the cached snapshot is loaded into that state with statuscachedbefore the live sync. So the stale startup pick likely predates #20183. I verified that in code at the parent commit, but I didn't run an older buildThe repro and control run above still hold. Here's a narrower suggestion that covers both the empty card and the device chip:
IndexDraftLanding, filter the most-recent-project pick to environments inliveShellEnvironmentIdsAtom(state/shell.ts:54). ShowNoProjectsHeroonly once every reachable environment is live, so it doesn't flash while cached data is loaded. Other environments can still connect later, which keeps the intent of fix(web): open the startup composer without waiting for every environment #20183ThreadDetailsPaneland its toggle when the draft's project doesn't resolve (ChatView.tsx:3731). The existing "Choose a project to start" headline already lets the user recover, so no new recovery screen is neededThe device chip needs no new picker once (1) is in. A "start without a project" draft has a real scratch project, so with more than one device the chip shows, and switching devices before sending already opens that device's scratch project (
useDraftEnvironmentRouting.ts:222-251). I read that in the code but haven't tested it with two devicesTradeoff: startup waits for the environment that holds the pick to be live. I haven't measured how long that takes for the desktop app's local server
Note
Approved by the author, posted by Claude Opus 5.5
Neonsy commentedon Oct 26, 2026
Extra information
I just removed my remote server, since I'm setting up a box somewhere else, so there are currently no other device online, which results in the issue not surfacing after running the same scrubber
So as the evidence stated, it seems to be connected to threads on other machines
Neonsy commentedon Oct 26, 2026
I removed the remote from both T3 Connect and Connections. Running the same local scrubber afterward shows the normal “What should we work on?” screen
Removing the saved connection excludes that remote from startup choices and clears its drafts. That fits a remote-owned bad draft disappearing, without proving remote threads themselves are the cause
The cache-accepting startup gate dates to #4055. #23967 later changed draft-opening timing, so source history alone doesn’t establish the exact introducing PR
Controlled source checks passed with simulated scheduling and storage. The original project-disappearance event and historical app reproduction remain unverified
Note
Approved by the author, posted by GPT-6.1 Sol
Neonsy commentedon Oct 26, 2026
Retested on
0.1.3-nightly.20261026.3717after scrubbing Windows and the remote. The bug persistedWith no projects, Chat was unavailable. I used Ctrl+P → Escape to reach projectless chat
I deliberately kept Local Storage and IndexedDB because wiping them would also remove data I want to preserve
That leaves client cache and drafts intact, so this still doesn’t rule out stale client state
Source confirms Chat is disabled with zero projects and unresolved drafts hide projectless recovery when no projects exist
My earlier recovery suggestion was incomplete. Preserve projectless recovery and route Chat to it when scratch is supported
This concludes my investigation. I can’t think of any further angles to try
Note
Approved by the author, posted by GPT-6.1 Sol
Neonsy commentedon Oct 28, 2026
IDK What happened, but whatever caused this seems to be gone now