MCP orchestration tools fail with `parent_not_active` after a provider handoff, a notification turn, or a question; a restart mid-turn kills the thread#23009

Summary

An agent thread calls the T3 Code MCP orchestration tools (delegate_task, watch_pull_request, task_status, schedule_task, t3_thread_send, t3_thread_launch). In three situations these calls fail with parent_not_active, even though the thread is running a turn and the agent is the one doing the work. A fourth problem: after a T3 Code restart mid-turn, the thread never runs again.

Setup: one long-lived "control" thread on the Claude provider, with two Claude provider instances configured (claudeAgent and claudeAgent_claude_2), scheduled tasks bound to that thread, and delegated child tasks. Work happens in a private repo.

1. After a provider-instance handoff of the thread

Steps:

1. A thread runs on claudeAgent.
2. The thread is handed to another instance of the same provider (for example claudeAgent -> claudeAgent_claude_2, or back), e.g. on an account switch.
3. In the next turn, call any orchestration tool.

Observed: every call returns parent_not_active for the rest of that run. Seen on:

• 2026-10-12 19:12: t3_thread_send to another thread failed 3 times.
• 2026-10-12 22:20: watch_pull_request and delegate_task.
• 2026-10-13 22:00 and 22:04: task_status for two finished child tasks, then every call (task_status, delegate_task) in that run.
• 2026-10-14 17:4x: delegate_task and watch_pull_request, after each handoff.
• 2026-10-16 ~15:50 onward: delegate_task and task_status for 3+ turns. Finished child results could only be read with t3_thread_read.
• 2026-10-20 18:14: delegate_task on every call.

2. In a turn started by a background task notification

Steps:

1. The thread starts a background task (or a scheduled task fires) and ends its turn.
2. The task-completion notification starts a new turn in the same thread.
3. In that turn, call an orchestration tool.

Observed: parent_not_active. Seen on:

• 2026-10-14 17:4x: delegate_task refused.
• 2026-10-21 00:05: schedule_task refused.

3. After a turn that asked the user a question, or during the daily thread handover

Steps:

1. The agent asks the user a question (AskUserQuestion) and the user answers.
2. In the turn that follows, call an orchestration tool.

Observed: parent_not_active. Seen on 2026-10-20 17:38: t3_thread_send failed twice right after the answer. The same error also shows up around our daily thread handover, when one long-lived thread hands its work to the next one.

4. After a T3 Code restart mid-turn, the thread never runs again

Steps:

1. A thread is in the middle of a turn.
2. T3 Code restarts (in our case the machine also rebooted later that morning).
3. Any later run of that thread (user message, scheduled task, queued wake-up).

Observed on 2026-10-21: the restart hit at 09:14Z. From 12:51Z every run of the thread failed with "Provider turn failed", the last ones with No conversation found with session ID <uuid>. The provider instance shown for the thread flipped between claudeAgent and claudeAgent_claude_2 across attempts. Nothing ran in that thread from 09:14Z to 14:23Z, when a new thread was started by hand and the scheduled tasks were rebound to it. A similar case on 2026-10-20 09:23: a scheduled-task thread failed with the same No conversation found with session ID error and had to be replaced.

Impact

Each case costs from one turn to several hours. When t3_thread_send failed, the user had to relay messages between threads by hand. When delegate_task failed, reviews and test runs stalled until the next scheduled turn (up to 30 minutes), or moved to local subagents outside T3. A missed schedule_task left a heartbeat missing for about 30 minutes. The restart in case 4 stalled all orchestration for 5 hours, a scheduled daily job did not run, and the user had to open a new thread and rebind 9 scheduled tasks by hand.

Expected behavior

• The run that currently owns a thread can call the orchestration tools. That includes the run after a provider-instance handoff, a run started by a task notification or scheduled task, and the run after a user answers a question.
• After a T3 Code restart, a thread either resumes its provider session or starts a clean new provider session with the thread history. It should not keep pointing at a session ID that no longer exists.

What would help

• Make "active parent" follow the thread, not the provider run that existed when the session was created. A handoff or a notification turn should transfer ownership.
• When the tool layer refuses a call, say why in the error: which run it expected and which run made the call.
• On No conversation found with session ID, drop the stale session and start a new one instead of failing every run.
• A way to rebind a thread's scheduled tasks and child tasks to a new thread in one step, for recovery.

Related: #16565 (provider switch), #16808 (background notification turn), #15103 (closed; same "No conversation found" symptom).