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

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.