[Bug]: New Chat project picker is scoped to the selected chat and a disconnected remote copy does nothing

[janpilu]

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. Have a project that exists both locally and on a remote machine (same repo / project).
2. Open a chat for that project on the remote machine, then disconnect the remote so it is offline / reconnecting.
3. Keep that disconnected-remote chat selected.
4. Click the New Chat / Start New Chat / new-thread icon.
5. In the project overview, select the project that is listed there.
6. Then switch to a chat that is local to this device, open New Chat again, and select the same project (now labeled local).

Expected behavior

New Chat should let me start a thread for the local copy of the project even if the currently selected chat belongs to a disconnected remote.

The project overview should not be limited to whatever environment the currently selected chat is on. If the project exists locally and on a remote, both should be available, and choosing a copy on an available machine should start a new chat.

If the only listed copy is on a disconnected remote, clicking it should not fail silently. It should either start a local chat or explain that the remote is unavailable.

Actual behavior

The New Chat project overview only shows what belongs to the currently selected chat.

• With a disconnected-remote chat selected, the overview only shows that project on the remote box. Clicking it does nothing.
• With a local chat selected, the overview shows the same project labeled "local". Clicking it starts a new chat as expected.

Starting a new local chat for a project that also exists on an offline remote therefore depends on already having a local chat selected.

Impact

Major degradation or frequent failure

Version or commit

0.0.41-nightly.20260916.1795

Environment

macOS (darwin 25.5.0), T3 Code Nightly desktop. Local machine plus a saved remote machine. The project exists on both.

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

Select an existing local chat first, then click New Chat. The project then appears as local and starting a new chat works.

Related

• fix(web): Cmd+Shift+N stalls while the selected remote computer is reconnecting #10548 is the same family (new chat while the selected remote is reconnecting), but it is about Cmd+Shift+N silently stalling, not this picker being scoped to the selected chat and a click doing nothing.
• [Bug]: Project filter only shows one entry when the project exists on multiple machines #11201 is about the project filter showing only one entry when a project exists on multiple machines. That matches the single-entry part, not the disconnected-remote click-does-nothing failure.
• [Bug]: Sidebar V2 (desktop): selecting a remote (Tailscale) project in the new-thread picker opens an existing thread — no way to start a new thread on a remote environment #5475 is about picking a connected remote project opening an existing thread instead of a new one.

[juliusmarminge]

Triage

Confirmed as a bug on current main. The New Chat / “New thread in…” project picker is scoped to the selected chat’s environment, and choosing a copy on a reconnecting remote can hang with no feedback.

What happens

Same-repo local and remote projects are grouped into one logical project. buildSidebarProjectPickerEntries then targets the member on the currently selected chat’s environment (apps/web/src/sidebarProjectGrouping.ts). Tests treat that as intended: one new-thread choice, follow the preferred environment.

The command-palette New Chat picker (apps/web/src/components/CommandPalette.tsx) and the draft hero project menu (apps/web/src/components/chat/DraftHeroHeadline.tsx) both use that builder. The palette description shows only the target machine, so the row is labeled with the remote name while a remote chat is selected, and Local after a local chat is selected.

Clicking that remote row calls handleNewThread on the disconnected environment. useHandleNewThread waits on t3.json when the project has no explicit defaultThreadEnvMode (readT3ProjectFileDefaultThreadEnvMode → executeAtomQuery with suspendOnWaiting: true, no timeout). The environment query factory returns Effect.never during supervisor connecting / backoff (UI reconnecting). The palette closes before run() finishes, so the click looks like a no-op: no draft, no toast.

canCreateProjectInEnvironment already treats connecting / reconnecting as unreachable, but only the add-project flow uses it.

That matches the report: the same project is offered as remote (dead click) or Local (works), and starting a local chat depends on already having a local chat selected. Direct create (chat.newLocal / single-project New Chat) has the same hang via startNewThreadFromContext, which inherits project and environment from the active thread.

Related

• fix(web): Cmd+Shift+N stalls while the selected remote computer is reconnecting #10548 is the same hang through Cmd+Shift+N. Related, not a duplicate: this report is the picker being scoped plus a click doing nothing.
• [Bug]: unsettled thread on a down machine blocks opening new threads until the machine serves again #6358 is the same t3.json wait after auto-opening an unsettled thread on a down host.
• fix(web): allow new threads when unsettled env is offline #7195 already skips the file read unless connected and retargets to a reachable sibling (primary preferred). The PR is open and conflicting with current main. It would fix the silent click, not listing both copies.
• [Bug]: Project filter only shows one entry when the project exists on multiple machines #11201 is the same single-entry grouping in the project filter (cosmetic). It does not cover the disconnected-remote click failure.
• [Bug]: Sidebar V2 (desktop): selecting a remote (Tailscale) project in the new-thread picker opens an existing thread — no way to start a new thread on a remote environment #5475 is about picking a connected remote opening an existing thread.

Suggested fix

1. Rebase or re-implement fix(web): allow new threads when unsettled env is offline #7195 so new-thread never awaits an environment file query unless the target is connected, and retargets to a reachable sibling when one exists.
2. Stop locking the New Chat picker to the selected chat’s environment. If the project exists locally and on a remote, both copies should be choosable (or the one row should prefer a connected machine).
3. If the only listed copy is unreachable, show a toast. Do not close the palette and hang.
4. Regression: reconnecting remote thread selected, shared project also present locally, no project defaultThreadEnvMode, pending t3.json → local copy is available or used; click must not hang.

Until that lands, the workaround stands: select an existing local chat, then use New Chat.