Orchestration instructions conflate resuming an interrupted review with requesting a fresh review#28734

Summary

When a user explicitly asks the parent agent to continue an interrupted delegated code review, the injected orchestration instructions steer it toward creating a new delegated task instead of resuming the existing child thread. Please distinguish continuation of unfinished work from an independent fresh review.

Observed environment

T3 Code on Windows, Codex parent, OpenCode child using DeepSeek V4.1 Flash Free. Observed November 1, 2026. Exact app build/version was not captured.

Steps to reproduce

1. Ask a Codex parent to delegate a code review to an OpenCode child.
2. Interrupt the child before its review finishes.
3. Later tell the parent: "Tell the DeepSeek instance to continue because I interrupted it last night."
4. The parent can read the original child with t3_thread_read, which reports status: interrupted and preserves its messages.
5. The parent nevertheless creates a new child using delegate_task, passing the old thread ID and instructions to recover prior work.

Relevant injected instruction

The parent receives this rule:

Every new delegate review or re-check is a new delegate_task (brief, findings, objections), never a t3_thread_send.

Meanwhile, the t3_thread_send tool documentation says its auto mode starts an idle thread, steers a running turn, or queues, and that sending to a finished child starts a fresh task in that child thread.

The rule does not explicitly distinguish resuming an interrupted review from commissioning another review. In this session, the parent interpreted it as requiring a replacement child despite the user's explicit continuation request.

Expected behavior

An explicit request to resume unfinished, interrupted work should reuse the existing child thread/provider context when supported. Creating an independent review or re-check should still create a new delegated task.

Actual behavior and impact

A replacement OpenCode child was launched. It was instructed to read the old thread and continue unfinished work, but this still requires context reconstruction and risks repeated analysis, extra latency/token use, and confusing continuity for the user.

Suggested improvement

Clarify the orchestration prompt with an exception such as:

For explicit continuation of an interrupted or paused delegated task, resume the existing child thread using the supported continuation tool. Use a new delegate_task for an independent review, re-check, or materially new scope.

If resuming through t3_thread_send cannot preserve task ownership/completion wakeups, provide a dedicated resume operation that does, or document that limitation explicitly.

Evidence boundary

This report is based on observed tool results and injected instructions, not an upstream source-code investigation. It does not establish that the runtime is technically incapable of resuming a child; the issue is the instruction ambiguity and resulting agent behavior. No private project content, credentials, or local thread IDs are included.

I searched existing issues for interrupted subagents and did not find an exact match.