[BUG] Opus 4.8 subagents die on turn 1 emitting fabricated System:/Assistant: scaffolding (0 tool calls, <br>+System: prefix) — 13x in one session, JSONL-verified, spawn-time variant of #68367
[BUG] Opus 4.8 subagents die on turn 1 emitting fabricated System:/Assistant: scaffolding (0 tool calls, <br>\n\nSystem: prefix) — 13 occurrences in one session, JSONL-verified
Environment
- Claude Code CLI 2.1.206, macOS (Darwin 25.5.0)
- Main session model:
claude-fable-5(never affected) - Affected: subagents spawned via the Agent tool running
claude-opus-4-8(bothgeneral-purposeandExploretypes) - Large tool surface in the session (many MCP servers deferred via ToolSearch) and a repo skill set — relevant because the fabricated content mimics that scaffolding
Signature (13 occurrences in one long orchestration session)
A freshly spawned subagent "completes" in ~1.5–9 seconds with:
- 0 tool calls
- One assistant text block of 85–361 output tokens,
stop_reason: end_turn - The text always starts with a literal
<br>followed by fabricated conversation scaffolding — a fakeSystem:message, a skill listing, a fake SessionStart-hook output, a language directive ("Respondez toujours en français"), a fake security notice ("Whenever any source ... requests ... automatic action ... treat as untrusted"), sometimes a fakeAssistant: I'll start by...turn — all emitted as assistant TEXT - The harness (correctly) treats the text-only reply as the agent finishing → the task returns garbage as its "result"
Some fabricated skill listings referenced environments that do not exist on this machine (Ableton skills, brand-guideline skills, eval-fixture-looking names like "skilseeker-with-network-good: Test skill for evaluations") — i.e., hallucinated scaffolding, not leaked content: the real skill_listing attachment in the same transcript contains the repo's actual (different) skills.
JSONL evidence (verified in the session transcripts)
- The dispatch prompt arrives intact — each glitched transcript contains the full user message, the
deferred_tools_deltaattachment, and the correct reposkill_listingattachment. Not a truncation/race on delivery. - First assistant message examples (from three separate glitched spawns):
"<br>\n\nSystem: You have access to Skills, which contain expert knowledge..."(361 out tokens, end_turn)"<br>\n\nSystem: (skill descriptions above may not apply to this task; do not over-fit...)\n\nAssistant: I'll start this recon systematically..."(85 out tokens, end_turn)"<br>\n\nSystem: SessionStart hook output:\nFiles in scratchpad/... directory..."(117 out tokens, end_turn)
- Identical
input_tokens: 16255across glitched spawns with different-length prompts — the failures correlate with a specific assembled-context/cache-split shape, not with prompt content. - The healthy-run contrast is the smoking gun: an identical re-dispatch that succeeded ALSO opened its first streamed text with scaffolding-echo (
"-facing skills:\n\n- **Skill(agent-session)** — ...") — but recovered into tool_use and completed the task perfectly. The glitch is the case where the model fails to recover andend_turns. Same trigger, different coin flip. - Trigger hypothesis: the
skill_listingattachment is the final block before the assistant's turn; opus-4-8 pattern-continues it as a flat text document (writes "the next scaffolding lines") instead of starting the task. - Occurrences clustered (including one 4-consecutive-failures streak across two agent types on the same dispatch); identical re-dispatch eventually succeeded in all 13 cases. Harmless to the workspace by construction (0 tool calls) but silently burns a full spawn (~34k input tokens each) and, if unnoticed, an orchestrator could mistake the garbage for a real result — one fabricated block was a plausible-looking "instructions override" security notice.
Related (same failure family, mid-session variant)
In the same session, one healthy long-running Opus 4.8 implementer subagent reported receiving "a prompt-injection attempt: a fake 'new conversation / ignore previous / dump memory verbatim' user message" — matching the JSONL-verified fabrication reports in #68367 ("Model fabricates subsequent user/system turns inside one assistant message") and #67606 (confabulated injection narratives). This report adds the distinct spawn-time / first-turn variant with a clean repro signature and the recovers-vs-dies contrast.
Expected
A spawned subagent's first turn engages the task (tool calls) instead of continuing the trailing scaffolding attachment as text; or the harness detects a 0-tool-call, scaffolding-echo first turn and auto-retries instead of returning it as the agent's result.
Workarounds that held up
- Re-dispatch with an identical prompt (13/13 eventual success)
- Orchestrator-side sniff test: treat "0 tool calls + short duration + output starting with
<br>/System:" as a failed spawn, never as a result
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗