[Bug]: GLM (ACP) handoff to git worktree fails every time with "provider event stream closed unexpectedly"; continuation stalls until manual re-prompt #36209

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. T3 Code desktop 0.1.5 on macOS, thread running GLM glm-5.3-flash via the ACP registry provider (acpRegistry_glm_agent, mode accept_edits), in a git project.
2. Mid-turn, have the agent call t3_worktree_handoff with a continuationPrompt.

Happens on essentially every attempt. Local DB shows 7 of 10 GLM runs that invoked t3_worktree_handoff since 2026-11-09 recorded as failed this way (2 completed, 1 user-interrupted); all 3 attempts today failed:

Expected behavior

As fixed for Codex in #24545: the handoff turn ends cleanly and the worktree-continuation run starts on its own in the new worktree.

Actual behavior

The handoff tool call itself succeeds — worktree created, branch bound, success payload returned — but the handoff run is recorded failed with the "Provider error / The provider event stream closed unexpectedly" banner, and the queued continuation never starts on its own. The user must send a new message manually to continue in the worktree; that run then works fine.

Timeline from the 10:50 AM failure today (run:thread:1c096fca-2949-4add-8991-8ee321d47964:ordinal:2):

15:50:27.488Z  dynamic_tool t3-code.t3_worktree_handoff starts
               input: { baseRef: "upstream/main", branch: "feat/strip-tracking-params",
                        continuationPrompt: "Implement the adaptation of …" }
15:50:29.198Z  tool call completes successfully
               output.structuredContent: { worktreePath: "/Users/daniel/.t3/worktrees/zapcooking/feat-strip-tracking-params", … }
15:50:29.185Z  worktree-continuation run requested (ordinal 3, status queued)
15:50:29.207Z  handoff run (ordinal 2) marked **failed** — "The provider event stream closed
               unexpectedly" — 9 ms after the tool result
15:52:26.791Z  ordinal 3 finally starts, only after the user manually re-prompts
15:52:59Z+     assistant messages flow; work continues normally in the new worktree

Notes:

• The GLM failure mode looks like the Cursor row of [Bug]: t3_worktree_handoff hangs Antigravity (AcpAdapterV2) runs in running forever because interruptTurn Interrupt escapes RunExecutionService before writeFinalRunEvents #35825 (handoff run reaches a terminal failed state with ProviderAdapterEventStreamError: Workspace changed.) combined with the Claude row of [Bug]: Grok thread stays running forever after t3_worktree_handoff; later messages stay queued #35274's table / [Bug]: Claude t3_worktree_handoff still fails the turn and its continuationPrompt never starts #22971 (continuation does not start until the user sends a message). Unlike Grok/Antigravity, the run does not hang forever.
• Same root-cause family as [Bug]: t3_worktree_handoff hangs Antigravity (AcpAdapterV2) runs in running forever because interruptTurn Interrupt escapes RunExecutionService before writeFinalRunEvents #35825 / [Bug]: Grok thread stays running forever after t3_worktree_handoff; later messages stay queued #35274: WorktreeMcpService.performHandoff rebinds the thread mid-turn → ProviderSessionManager.detach → failSubscribers("Workspace changed.") → ProviderAdapterEventStreamError on the still-open run.
• Diagnosability nit: on 0.1.5, ~/.t3/userdata/logs/server.trace.ndjson contained zero entries mentioning ProviderAdapterEventStreamError / "event stream" / "Workspace changed" for these failures — the only trace was the UI banner. The failed-run payloads in statev2.sqlite also carry no error cause, which made this report harder to assemble than it should be.

Impact

Major degradation or frequent failure

Version or commit

0.1.5 (desktop app and server)

Environment

macOS (Apple Silicon), T3 Code desktop/server 0.1.5, provider instance acpRegistry_glm_agent (GLM glm-5.3-flash over ACP), turn mode accept_edits, thought_level: max

Logs or stack traces

No stack trace available: the failure is not present in server.trace.ndjson (see note above). Evidence above is from orchestration_v2_projection_runs / orchestration_v2_projection_turn_items in ~/.t3/userdata/statev2.sqlite plus the UI banner screenshot.

Workaround

Re-prompt after the "Provider error" banner; the next run starts in the new worktree and behaves normally.