[Bug]: Attachment uploads fail with parent_not_active after failed provider handoff, even on fresh turn #28935

Summary

After a failed provider handoff in a long-lived T3 Code thread, the original provider can continue working and successfully produce an artifact, but attachment write tools fail with parent_not_active. A fresh user turn in the same thread does not necessarily recover attachment delivery.

Related: #16565 (stale MCP provider credential after switching back to a reused session), #23006 (broader parent_not_active after handoffs).

Reproduction observed

1. Use a long-running thread with Claude as the active provider; attachment uploads previously work in that same thread.
2. Attempt to switch to Grok. The target provider run fails almost immediately during handoff, before any Grok prompt is sent.
3. Resume Claude in the same thread.
4. Build an unsigned iOS IPA successfully; verify the artifact exists and its checksum is stable.
5. Call t3_attachment_prepare_upload to deliver it to the thread.
6. Receive parent_not_active: The calling provider no longer owns an active thread run.
7. Start another fresh Claude turn in the same thread and retry preparing the upload. The same error persists.

The upload URL is never issued; no bytes are uploaded. The file itself is not the cause.

Expected

An active provider turn should be able to prepare an attachment upload and send an attachment to its thread, including after a failed handoff. If the provider's MCP credential is stale, T3 should rotate/rebind it when the new run starts, or surface a recoverable error.

Actual

t3_attachment_prepare_upload fails at the caller-ownership gate. No upload can begin. The same gate also applies to t3_thread_send_attachments, so bypassing preparation would not solve delivery.

Diagnostic evidence

• Before the failed switch, attachment preparation succeeded multiple times in this thread.
• A Grok handoff run failed within roughly 100 ms; Claude subsequently received a context-handoff marker.
• Attachment preparation then failed twice in the resumed Claude turn and again in a fresh Claude turn.
• A separate thread showed a similar failure after a Codex handoff rejected for insufficient context allowance; attachment preparation later succeeded after an application/Mac restart.
• Local inspection of the packaged orchestration code showed that write tools check a live shell, matching provider instance, and an active run (or qualifying pending subagent). MCP credentials are scoped to provider session and provider instance. The exact mismatched predicate in this incident was not directly observed.

Suspected cause (not confirmed)

A failed provider switch may leave the thread's live shell/run projection and the provider-scoped MCP credential out of sync. Reusing the old provider session may not refresh the credential appropriately. This resembles #16565, but the user-facing failure here is attachment delivery, including after a new turn.

Impact

Completed artifacts cannot be delivered through T3 Connect despite successful builds. Repeating the build wastes time and resources without fixing the ownership failure. A new thread or restarting T3 may recover, but same-thread fresh turns did not.

Suggested investigation

• Refresh or validate MCP credentials against the actual run's provider instance at every run start, including reuse of an existing provider session.
• Ensure a rejected handoff does not revoke or strand the previous provider's usable write credential.
• Add a regression test: successful Claude attachment → failed cross-provider handoff → resumed Claude turn → successful t3_attachment_prepare_upload and t3_thread_send_attachments.
• Consider a recoverable diagnostic that distinguishes stale credentials from a genuinely inactive caller.

Privacy

This report intentionally omits local usernames, filesystem paths, thread IDs, tokens, and artifact contents.