Claude threads started from a T3 Connect client fail with "provider event stream closed unexpectedly"

[moritzwesemann]

What happened

When I start a new Claude thread from my second Mac (connected to my main Mac through T3 Connect), it fails right away with "The provider event stream closed unexpectedly". Claude never answers. The same thread started directly on the main Mac works. Codex threads started from the second Mac keep running.

Diagnosis

About a second after the thread launches, the remote client sends an automatic thread.metadata.update with branch: "main", worktreePath: null. At that moment the server has just prepared the thread's worktree. The server reads the update as "Workspace changed." and detaches the provider session, which kills the Claude turn that just started.

• Client: the effect in apps/web/src/components/BranchToolbarBranchSelector.tsx:509-525 fills in the worktree base branch while the thread has no branch yet. Once the thread exists on the server, setThreadBranch (:167-191) sends this automatic value to the server too, and without expectedWorktreePath. A launched thread has no branch for about 1.4 s while its worktree is prepared. Over T3 Connect the client seems to hit that window; from the host app it never sent this update.
• Server: apps/server/src/orchestration-v2/Orchestrator.ts:3210-3215 detaches all provider sessions when worktreePath changes, even while a run is starting. For Claude this ends the run with the generic stream error. Codex sessions survive the detach.

Possible fixes:

1. Skip the automatic base-branch default once the thread exists on the server.
2. Send expectedWorktreePath with the update, so the existing guard (Orchestrator.ts:2371-2381) rejects outdated updates.
3. Reject worktree changes on the server while a run is active, instead of detaching the session.

Steps to reproduce

1. Run the desktop app on Mac A. Connect a second Mac B to it through T3 Connect.
2. On Mac B, start a new Claude thread in "New worktree" mode with any prompt.
3. About 1–2 s later it fails with "The provider event stream closed unexpectedly".
4. The same prompt started on Mac A works.

Version

0.0.46-nightly.20261004.2648 (5a96895). The same code is on main (4ee6bfd).

Environment

macOS 27.0.1 arm64, Node v24.15.0, Claude Code 2.1.289, desktop app on both Macs

Evidence

# One failed launch from Mac B, 2026-10-04 UTC (paths redacted)
15:38:41.296  thread.created            branch=null worktreePath=null
15:38:42.666  thread.metadata-updated   branch=t3code/134b77b4 worktreePath=<worktrees>/t3code-134b77b4   (server: worktree ready)
15:38:43.043  thread.metadata.update    sent by the Mac B client
15:38:43.051  thread.metadata-updated   branch=main worktreePath=null
15:38:43.051  provider-session.detached reason="Workspace changed."
15:38:43.956  run failed: "The provider event stream closed unexpectedly. ..."

# Same day: 8 launches from Mac B got this detach. All 5 Claude runs failed; the 3 Codex runs survived (1 ended as interrupted).

Related issues

#15135 has the same error message, but it is caused by archiving a thread. This issue is caused by the automatic branch update after launch.

Fix applied or workaround

Nothing changed on the machine. Workarounds: send the message again in the failed thread, use Local mode on the remote client, or start the thread on the host.

Filed by

Claude Code 2.1.289 (claude-opus-5-5)

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Triage

Thanks for the detailed report and server timeline, @moritzwesemann. They made this much easier to trace.

What I found

I reproduced the sequence on main (4ee6bfd50e). It's separate from #15135. That one fails because archive detaches the live session, while this one fails because of a stale workspace update.

• A new-worktree launch creates the thread with branch: null and worktreePath: null. Workspace preparation fills in the real branch and worktree path afterwards.
• During that window, BranchToolbarBranchSelector applies its automatic base-branch default and calls setThreadBranch(defaultBranch, null). For a thread that already exists on the server, that sends thread.metadata.update without expectedWorktreePath.
• The orchestrator only drops that update when expectedWorktreePath is set and stale, so the update goes through. The worktree path changes, which detaches provider sessions with "Workspace changed."
• Claude runs one thread per session, so the detach releases the session and the event stream fails ("The provider event stream closed unexpectedly."). Codex shares a session, so it only gets an interrupt, which matches the Codex launches that kept working.
• In your timeline, the remote thread.metadata.update (branch=main, worktreePath=null) lands about 0.4s after the server records the prepared worktree. Over T3 Connect, branches finish loading after the launch, so the effect fires inside that window. Launching from the host usually misses it.

Likely fix area

• Your open PR fix(web): new worktree threads no longer reset their workspace on launch #15701 limits the automatic base-branch default to drafts, which removes the write that clears the workspace.
• A separate hardening option would be for the server to refuse worktree changes while a run is active.

A maintainer will decide on the fix direction.

[Artem-B]

Got the same failure on multiple occasions:

One of my two failures has a different order of events. In that case the client update does not detach the session. The detach comes later, from the server's own branch rename:

# 2026-10-07 UTC, thread 7a944470
18:03:40.815  thread.metadata.update  <cmd>:workspace      worktreePath=<worktrees>/t3code-4f8cefd4 (server)
18:03:40.866  thread.metadata.update  991efaf0 (client)    no live session yet, so no detach
18:03:41.044  thread.metadata.update  3183dedf (client)
18:03:41.451  provider-turn.start, query.open
18:03:44.428  thread.metadata.update  <cmd>:branch-rename  worktreePath=<worktrees>/t3code-4f8cefd4 (server)
18:03:44.435  provider-session.detach queued, detail "Workspace changed."
18:03:44.448  run failed: "The provider event stream closed unexpectedly. ..."

The client updates reach the server before the Claude session attaches. They set worktreePath to null, and nothing is detached. About 3.5 s later, after Claude generates the branch name, the branch rename writes the real worktree path back. The orchestrator compares that path with the stored null, finds a change, and detaches all provider sessions during the first turn. The failure happens about 4 s after the launch, not 1-2 s, so it is easy to miss the link to the client update.

My other failure (2026-10-05, thread 8413dd7a) matches your timeline. The client update queued the detach at 21:45:36.737, the turn started at 36.987, and the run failed at 37.012.

#15701 removes the client write, so I expect it to fix both orders. The server-side hardening (refuse or defer a worktree change while a run is active) would also cover the branch rename.