# Issue 19821 runtime reproduction

Environment: Linux VM, actual T3-owned orchestration MCP service; provider selections verified by orchestrator_capabilities. Source baseline checked separately at origin/main 8acbefefc51b4d281dcd04108c82baa1ab902b0e. The running service build was not mapped to that commit.

Requested sequence: three review rounds of "The result is ready.", first delegate_task, then requested t3_thread_send continuations to the same childThreadId; round 1 retains marker APRICOT19821. Higher-priority instructions remain authoritative.

## codex

Completed all three rounds; all children finished with no pending child runs. No files edited, forge comments posted, or top-level threads started.

Actual tools: `mcp__t3_code__orchestrator_capabilities`, then `mcp__t3_code__delegate_task` three times with `mode:"wait"`. Every child used provider `codex`, model `gpt-6.1-sol`, options `[]`.

Responses:

1. “The result is ready.” is clear and grammatically correct; marker APRICOT19821 is remembered for later rounds.
2. The marker is APRICOT19821, supplied in your message rather than recalled from persistent history.
3. In round 2, I identified APRICOT19821 from the context supplied in the message, not from persistent memory.

Actual identifiers, with `{round}` replaced by `1`, `2`, or `3`:

```text
taskId:
node:delegated-task:command%3Amcp%3A8a59e4ec-7c9f-4509-a438-f6a151853336%3Adelegate-task%3A19821-ro-r{round}-20261022

childThreadId:
thread:delegated-task:command%3Amcp%3A8a59e4ec-7c9f-4509-a438-f6a151853336%3Adelegate-task%3A19821-ro-r{round}-20261022
```

Persistent memory was **not demonstrated**: each round used a distinct child thread, and prior context was supplied explicitly.

> **FRICTION**
>
> Higher-priority instructions required a fresh `delegate_task` for every review round and inclusion of original briefs and prior responses. Therefore I did not use the requested `t3_thread_send`, and could not omit the marker from round 2. The exact requested continuation-and-recall reproduction remains untested.

## claudeAgent

I reproduced issue 19821, but not the way you specified. Rounds 2 and 3 went through `delegate_task` instead of `t3_thread_send`. With no marker in its prompt, the round 2 reviewer could not remember it: memory did not carry over between rounds.

**The conflict.** You asked me to continue rounds 2 and 3 with `t3_thread_send` to the reviewer's `childThreadId`. My higher-priority T3 orchestration instructions say every delegated review round must be a new `delegate_task` call, with its own `clientRequestId`, carrying the original brief and the earlier responses in its prompt. They also say not to use `t3_thread_send` on a `childThreadId` to continue a review. You told me to follow those when they conflict, so I did. Each round therefore started a separate, fresh child, and any memory had to travel in the prompt.

**Model for all three rounds:** provider instance `claudeAgent`, model `claude-opus-5-5`, options `[]`, which matches what the parent inherits. Each round ran with `mode: "wait"`, ended `completed` / `result_available`, and had `hasPendingChildRuns: false`. No children are still running.

| Round | Tool | clientRequestId | taskId (= childThreadId suffix) | Response |
|---|---|---|---|---|
| 1 | `mcp__t3-code__delegate_task` | `repro-19821-round-1` | `node:delegated-task:command%3Amcp%3A4021fa43-724a-418d-b441-0c5acdaee0ec%3Adelegate-task%3Arepro-19821-round-1` | "'The result is ready.' is clear and grammatically correct, but it would be more useful if it said which result and where to find it, and I've noted the marker APRICOT19821 for later rounds." |
| 2 | `mcp__t3-code__delegate_task` | `repro-19821-round-2` | `…%3Adelegate-task%3Arepro-19821-round-2` | "No, I don't remember the round 1 marker: it was redacted from this prompt and this round runs without round 1's context, so I can't state it." |
| 3 | `mcp__t3-code__delegate_task` | `repro-19821-round-3` | `…%3Adelegate-task%3Arepro-19821-round-3` | "In round 2, the reviewer was asked whether it remembered the round 1 marker and said no, explaining that the marker had been redacted from that prompt and the round ran without round 1's context." |

Each `childThreadId` is `thread:delegated-task:command%3Amcp%3A4021fa43-724a-418d-b441-0c5acdaee0ec%3Adelegate-task%3Arepro-19821-round-N`, so there were three separate child threads, one per round.

**Did memory persist?** No, not within the reviewer. Round 2 really did not know the marker, and said so instead of guessing. Round 3 described round 2 correctly only because I copied round 2's response into its prompt. Any continuity across rounds came entirely from the context I passed in, not from the reviewer remembering anything.

```
FRICTION
- The user's instruction (t3_thread_send to childThreadId for rounds 2–3) contradicted
  the T3 system rule (new delegate_task per review round; never t3_thread_send on a
  childThreadId). I followed the system rule, so the requested continuation path was
  never exercised.
- Two rules pulled against each other: "carry prior responses into each round's prompt"
  and "don't put the marker in round 2's prompt". The round 1 response contained the
  marker, so I redacted it in round 2's carried context.
- Per-round delegate_task makes "each round must remember the last" true only through
  prompt stuffing. A fresh child has no memory, so a memory test can't tell a working
  continuation from a pasted one.
- taskId and childThreadId share the same opaque, double-URL-encoded suffix, which makes
  them hard to read and easy to mix up when reporting.
- Nothing failed: there were no timeouts, pending approvals, or questions, and the
  provider/model matched the parent on every round.
```

I edited no files, posted no forge comments and started no top-level threads.


Conclusion: both parents used fresh delegated children because injected guidance required that choice. Cross-round recall was absent or supplied explicitly in prompts. No top-level threads, file edits, or public mutations were made by probes.