fix(web): Cmd+Shift+N stalls while the selected remote computer is reconnecting

[coygeek]

Summary

On macOS, Chat: New Local (Cmd+Shift+N) does nothing visible when the selected thread belongs to an offline remote computer that T3 Code is trying to reconnect to. Selecting a thread on the available local computer makes the same shortcut work again. The remote computer is confirmed offline; the UI shows it as reconnecting.

Steps to reproduce

1. Use the desktop app with an available local environment and a saved remote environment, each with an existing thread.
2. Leave the remote computer offline while T3 Code continues trying to reconnect to it.
3. Select an existing thread belonging to that remote environment. Confirm the composer shows the remote computer as reconnecting.
4. With the integrated terminal unfocused and the command palette closed, press Cmd+Shift+N, bound to chat.newLocal with when: !terminalFocus.
5. Observe that no new draft opens. Select an existing thread belonging to the available local environment and press the same shortcut; it works there.

These steps describe the reported interaction and supplied screenshots, not a separately recorded reproduction. To isolate the source path below, use a remote project with no explicit defaultThreadEnvMode and a t3.json file query that needs fetching or revalidation. The remaining runtime evidence gap is whether that file query was pending during the reported keypress; the affected project's defaults and query-cache state were not captured. Failure with a healthy remote connection has not been established.

Expected behavior

The new-chat action should respond while the selected remote computer is unavailable. Opening a draft should not silently wait for that computer to reconnect. If creation cannot proceed, the action should give clear, actionable feedback so the user can select an available environment and continue working.

Actual behavior

The shortcut produces no visible navigation or action-specific feedback while the offline remote thread is selected. Switching to an available local thread restores the shortcut. The existing reconnecting banner remains visible, but does not explain why opening a new chat is waiting.

Affected area

apps/web new-thread shortcut and draft creation, as used by apps/desktop; the environment query behavior lives in packages/client-runtime.

Runtime or environment

• macOS 26.6.2, T3 Code desktop with local and remote Mac environments.
• Installed app inspected during investigation: 0.0.40-nightly.20260907.1359. The supplied screenshots do not independently establish their exact build.
• Remote MacBook is offline, confirmed by the reporter; the client displays reconnecting/trying again.
• Upstream source inspected at 1d1bf50405ccca8fdb8b57879d9def379e27a550.

Evidence

The supplied keybinding screenshot shows Chat: New Local, Cmd+Shift+N, and !terminalFocus. The failing screenshot shows a remote thread with a reconnecting banner. The reporter confirms the same shortcut succeeds after selecting a local thread. Screenshots contain unrelated conversation content and personal machine identifiers, so their relevant UI state is transcribed here.

Current upstream has a concrete wait path consistent with this failure:

1. _chat.tsx:80-89 consumes chat.newLocal and invokes startNewThreadFromContext. chatThreadActions.ts:69-101 selects the active thread's project and environment. Despite the command's name, it does not force the current computer as the destination.
2. useHandleNewThread.ts:154-167 awaits the project's t3.json when the project has no explicit environment-mode default. The fresh-draft path awaits this resolution before registering the draft and navigating; reopening an empty stored draft can await it too.
3. t3ProjectFileDefaults.ts:21-39 awaits the environment file query without an abort signal or a timeout at this call site. executeAtomQuery uses suspendOnWaiting: true.
4. The environment query factory returns Effect.never during connecting and backoff. A file query needing a result can therefore keep draft navigation pending while retries continue. The explicit runtime phase offline instead fails the query; a physically offline computer being retried is the relevant distinction here.

This verifies a blocking mechanism in source, not the exact runtime cause in the installed app. No keyboard trace or end-to-end reproduction was captured.

Impact

Major degradation or frequent failure in the offline-remote workflow: the new-chat shortcut appears broken and the user must first leave the remote thread to start another chat through it.

Additional context

Workaround: select an existing thread on the available local computer, then press Cmd+Shift+N.

Regression check: with the remote computer offline and the client retrying, select its thread and invoke chat.newLocal with a pending project-file query. The issue remains reproducible if the action silently waits without opening a draft or providing actionable feedback. It is resolved when the action responds without waiting indefinitely for reconnection, local creation still works, and existing draft content is preserved.

Existing issues were searched before submission. #8924 concerns settling or dismissing cached offline threads, which is a different action and closure condition from this new-chat failure.

[juliusmarminge]

Triage

Confirmed as a bug on current main. Cmd+Shift+N (chat.newLocal) can hang with no action-specific feedback while the selected remote environment is still retrying.

What happens

chat.newLocal is the contextual “new in this project” command (the shift-click twin of New Thread). Despite the settings label Chat: New Local, it does not target the local computer. _chat.tsx calls startNewThreadFromContext, which inherits the active thread’s project and environment.

useHandleNewThread then waits on the project’s t3.json when that project has no explicit defaultThreadEnvMode. That read goes through readT3ProjectFileDefaultThreadEnvMode → executeAtomQuery (suspendOnWaiting: true) with no abort or timeout. The environment query factory returns Effect.never during supervisor connecting / backoff (UI phase reconnecting). A physically offline host that is still being retried therefore never settles the query, so draft registration and navigation never run.

That matches the report: the shortcut looks dead on the reconnecting remote thread, and works again after selecting a local thread. The existing reconnecting banner (“Trying again”) does not explain the wait. Explicit runtime phase offline fails the query instead of hanging; the retrying/reconnecting case is the important distinction.

The remaining evidence gap in the original report still stands: we did not capture whether that file query was pending at the keypress. The source path is enough to accept the bug.

Related

• [Bug]: unsettled thread on a down machine blocks opening new threads until the machine serves again #6358 is the same hang (New Thread blocked on t3.json against a down host) via a different entry path (auto-open of an unsettled remote thread). Related, not a duplicate of this shortcut/reconnecting case.
• fix(web): allow new threads when unsettled env is offline #7195 already implements the right guard: skip the t3.json read unless connection.phase === "connected", and retarget to a reachable sibling when one exists. canCreateProjectInEnvironment already treats connecting / reconnecting as unreachable. The PR is open and stale against current main.
• [Bug]: Threads from an offline T3 Connect environment cannot be settled or dismissed #8924 is about settling/dismissing cached offline threads, not this new-chat wait.

Suggested fix

1. Rebase or re-implement fix(web): allow new threads when unsettled env is offline #7195 so chat.newLocal never awaits an environment file query while the target is not connected.
2. Add a regression: selected remote thread in reconnecting/backoff, no project defaultThreadEnvMode, pending t3.json query → a draft opens or the user gets a toast; the action must not wait indefinitely.
3. Optional defense in depth: pass an abort/timeout through readT3ProjectFileDefaultThreadEnvMode.

Until that lands, the workaround stands: select a thread on an available local computer, then press Cmd+Shift+N.