[Bug]: Pi worktree handoff reports Provider error despite a successful workspace transition and continuation #21573

Before submitting

• I searched existing issues and did not find an exact duplicate for this Pi worktree-handoff behavior.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Summary

With the Pi provider, a successful t3_worktree_handoff is immediately followed by a failed outgoing run and a visible Provider error:

The provider event stream closed unexpectedly. Retry the turn; if it keeps failing, check the provider and server logs.

The handoff tool explicitly says the old provider session will detach, and a continuation run is already queued. In several observed cases, that continuation completes successfully. The expected session shutdown appears to be classified as an unexpected provider failure.

This makes normal workspace transitions look like provider/API reliability failures and encourages unnecessary retries.

Steps to reproduce

The following minimal sequence is based on the observed sessions; it has not been separately rerun in a clean installation:

1. Open a Git project in the Windows desktop app.
2. Start a thread in the project's root checkout, using Pi with an OpenAI Codex model.
3. Have the agent call t3_worktree_handoff to create and switch to a worktree, with a continuation that performs a simple action in the new workspace.
4. Observe the outgoing run's status and error item as the old Pi session detaches.
5. Observe that the continuation can start and finish in the new worktree despite the outgoing run being marked failed.

This concerns migrating the current thread, not launching a separate thread with workspaceStrategy.

Expected behavior

A successful workspace handoff should end the outgoing run with an intentional transition status, not a provider failure. The continuation should proceed in the new workspace without an alarming retry message for the intentionally closed session.

Unexpected provider exits should still surface as errors; only the planned handoff detach should be distinguished.

Actual behavior

• The worktree is created and the handoff tool reports success.
• The tool reports continuation.status: "scheduled" and delivery: "queued".
• During the detach, T3 marks the outgoing run failed and adds a Provider error item with failure.class: "unknown".
• A continuation can run successfully immediately afterward.

Read-only inspection of local T3 run projections and Pi native session records found 10 Pi runs marked failed between October 16 and October 19, 2026. All 10 failures coincide with successful t3_worktree_handoff calls and have the same event-stream-closed message. This is a count of failed runs inspected, not a measured failure rate across all handoffs.

At inspection time, the immediate continuation runs were: 6 completed, 3 cancelled, and 1 running. The cancellation causes were not established; this report does not attribute them to the handoff bug.

Impact

Frequent false failure reports during worktree migration. Continuation can still succeed, but users cannot reliably distinguish an intentional workspace transition from a genuine provider outage and may retry work unnecessarily.

Version or commit

Latest occurrence: 0.1.1-nightly.20261018.3335.

The inspected failures span several days; older occurrences may have used earlier nightly builds.

Environment

• Windows desktop app, OS build 10.0.26200.7462.
• Provider driver/instance: pi.
• Installed Pi package: @earendil-works/pi-coding-agent 1.3.0 at inspection time.
• Model selection in the affected runs: openai-codex/gpt-6.1-sol, thinking xhigh.
• Git project, migrating from the root checkout into a worktree.

Logs or stack traces

Representative timeline from the latest occurrence, in UTC. User prompts, project names, local paths, and session identifiers are omitted:

2026-10-19T07:17:06.661Z  Pi assistant calls t3_worktree_handoff
2026-10-19T07:17:09.259Z  T3 continuation run is requested
2026-10-19T07:17:09.265Z  T3 marks outgoing run failed; adds Provider error
2026-10-19T07:17:09.276Z  Pi records the successful handoff tool result
2026-10-19T07:17:19.801Z  Continuation attempt starts

Relevant fields from the successful handoff tool result, with workspace paths and branch names omitted:

{
  "setupScript": { "status": "no-script" },
  "continuation": { "status": "scheduled", "delivery": "queued" },
  "note": "Handoff recorded. Changing the workspace detaches this provider session, so the current turn ends shortly after this call; the queued continuation prompt then starts the next turn inside the worktree with the conversation preserved. The worktree is not removed automatically when the thread is deleted."
}

Relevant fields from T3's outgoing error item:

{
  "type": "error",
  "status": "failed",
  "title": "Provider error",
  "failure": {
    "class": "unknown",
    "message": "The provider event stream closed unexpectedly. Retry the turn; if it keeps failing, check the provider and server logs.",
    "code": null,
    "retryable": null
  }
}

The inspected Pi session records around these transitions contain successful handoff tool results, not an upstream OpenAI API error explaining these particular failures. The exact internal control-flow cause has not been verified from source; the evidence points to planned-session-detach handling or terminal-status classification.

Related issues

• [Bug]: Claude child task dies after t3_worktree_handoff; continuation turn never starts #15136 reports the same unexpected-stream-close symptom during a Claude child worktree handoff, but its continuation never starts. This report concerns Pi current-thread handoffs, including continuations that complete successfully.
• [Bug]: Pi ProviderAdapterEventStreamError: Failed while streaming pi provider session provider-session:provider-instance #21208 concerns Pi stream errors after an update or a long idle period. The trigger here is an explicit successful worktree handoff, not update/idle recovery.

Workaround

Select or create the intended worktree before starting the task, avoiding a mid-turn workspace migration. If a handoff has already happened, check whether the continuation is running before retrying the original task.

Privacy

This report intentionally includes only sanitized diagnostic excerpts. No original user prompts, conversation transcripts, credentials, or local workspace paths are attached.