[lukemaj]

What: Chromeria's agent instructions now say: to continue the same delegated job after it stopped (question answered, access granted, blocker cleared), send to its childThreadId with t3_thread_send and wait with t3_thread_wait; start a new delegate_task only for independent work such as a fresh review round.
Why: The instructions only covered review rounds, so agents restarted blocked jobs in a fresh child and lost its context (App Store Connect setup, 2026-10-09).
So what: Ready for the user's merge approval; it takes effect for agents after the next Chromeria build.

Closes #203.

How

Three text changes, keeping upstream's wording and appending the continuation rule: the injected orchestration instructions, the short tool-use block, and the t3_thread_send description. They state upstream's contract that follow-up results land in task_status.latestTerminal* and do not wake the parent (pingdotgg/t3code#13490; the wake change in #14030 was closed for lacking a scope ruling), so the parent waits on the thread itself.

Proof

• New fork-owned apps/server/src/mcp/delegatedTaskContinuation.test.ts asserts the rule in all three texts: 1 passed. Upstream test files are untouched (first push edited them and failed CI's fork check).
• vp lint/vp fmt on changed files: no errors. tsc --noEmit for apps/server: passed (only existing suggestions).
• fork-check --base 12069eefd7 on the committed head: OK (25 features).
• Independent review (GPT-6 Luna) against the server code: no blocking findings.

Elon record

Requirements and who asked: User asked to fix inside Chromeria that agents restart instead of continuing a delegated job.
Deleted: Implementing follow-up wakes (upstream contract), a new tool parameter.
Bottleneck: Agents follow injected instructions, which only covered review rounds.
Checked myself: Instruction sources, t3_thread_send description, upstream triage on #13490, test and typecheck output.

Model: Claude Opus 5.5 in Claude Code (Chromeria thread).

🤖 Generated with Claude Code

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	5.0 KiB	5.0 KiB	0 B (0.0%)	6.8 KiB	✅
Codex	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Codex	Live turn WebSocket wire	1.2 KiB	1.2 KiB	0 B (0.0%)	2.0 KiB	✅
Codex	Live turn WebSocket decoded	20.9 KiB	20.9 KiB	0 B (0.0%)	29.3 KiB	✅
Codex	Live turn messages	2	2	0 (0.0%)	8	✅
Claude	Total thread wire	5.0 KiB	5.0 KiB	0 B (0.0%)	6.8 KiB	✅
Claude	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Claude	Live turn WebSocket wire	1.2 KiB	1.2 KiB	0 B (0.0%)	2.0 KiB	✅
Claude	Live turn WebSocket decoded	21.2 KiB	21.2 KiB	0 B (0.0%)	29.3 KiB	✅
Claude	Live turn messages	2	2	0 (0.0%)	8	✅

Baseline: ef1f915 · PR result: 60422d4 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 108.5 KiB
• Claude decoded thread snapshot: 108.8 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[lukemaj]

Independent review (GPT-6 Luna) against server code at base ef1f915: no blocking findings. Confirmed t3_thread_send to a delegated child works from a live parent within mode ceilings, t3_thread_wait waits on the child's latest run, and follow-up results appear in task_status.latestTerminal* without another parent delivery (OrchestratorMcpService.ts, ThreadManagementService.ts, Orchestrator.ts).