Let a same-scope re-check continue the original reviewer with t3_thread_send

[Divers-Mona]

Since this was moved to Ideas, I'm restating it as a proposal. I understand the stricter wording in #24850 may be intentional.

Area

apps/server

Scenario

1. On nightly 3669 or later (includes feat(server): cut T3's agent instructions and tool copy by 60% #24850).
2. A parent agent delegates a review with delegate_task; the reviewer returns a must-fix finding and the author fixes it.
3. The parent needs that same reviewer to re-check the fix.

Current guidance

#24850 changed the guidance to:

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

and added tests that assert it (CodexDeveloperInstructions.test.ts, McpHttpServer.test.ts). So every re-check now has to go to a fresh reviewer, which re-reads the whole change and loses the context it used to raise the findings it is checking, plus the parent's prompt cache for that child. This replaces the distinction #24560 introduced.

We agree with the other half of the same line ("Fix small review findings yourself; start no delegate for them"): skipping re-checks for small findings is a good change. This report is only about how a re-check that is still needed reaches the reviewer.

Proposal

As in #24560 (which fixed #19821): independent review rounds start a fresh delegate_task, while a same-scope re-check that needs the reviewer's own context continues the reviewer with t3_thread_send on its childThreadId. t3_thread_send still supports this path: a follow-up to a completed child starts a new tracked task, returns its taskId, and notifies the parent.

Could the guidance keep the #24560 distinction, or make this configurable? If agents were misusing t3_thread_send for independent reviews, keeping the distinction seems a narrower fix than banning the path.

Version or commit

Current guidance since v0.1.3-nightly.20261025.3669 (5f64c5e); earlier behavior from #24560 (909e4c9).

Environment

Windows 11, T3 Code desktop nightly; Claude Opus 5.5 parent delegating reviews to Codex GPT-6.1 Sol.

What I do for now

Stay on v0.1.3-nightly.20261025.3655, or override the rule in user-level agent instructions.

[omry]

I’m evaluating T3 as an alternative to VS Code for long-running workflows, and this is a major blocker.

I need the original reviewer to verify fixes. Starting a new reviewer for every re-check repeats code reading and context reconstruction, adding latency and token cost.

T3 already supports continuing the same subagent conversation. Why prevent user-defined workflows from using that through a non-overridable global instruction?

If a particular review process needs fresh delegates, it should enforce that through its own private API or workflow option.

I support restoring #24560’s distinction, or adding API-level flexibility to reuse an existing subagent conversation.

Thank you.

[omry]

As a temporary workaround, I tried 0.1.3-nightly.20261025.3655. With it, I was able to reuse the same reviewer conversation, as my established workflow requires.

But T3’s instructions still conflict with my final review. That step uses a fresh reviewer without previous findings, to avoid anchoring. The injected instruction says: “Include the original brief, prior findings, responses, and unresolved objections in each new task prompt.” This wording is also present in #24560:
https://github.com/pingdotgg/t3code/pull/24560/files

In my session, Codex treated this as higher priority than my workflow and stopped before launching the fresh review, even when I explicitly asked it to follow my workflow.

Could reviewer context be controlled by the workflow instead? If a particular review process requires this context, a workflow-scoped option or internal API would avoid imposing that requirement globally.