[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

Open 💬 1 comment Opened Jul 11, 2026 by DBAElegance

[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 (both general-purpose and Explore types)
  • 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 fake System: 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 fake Assistant: 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)

  1. The dispatch prompt arrives intact — each glitched transcript contains the full user message, the deferred_tools_delta attachment, and the correct repo skill_listing attachment. Not a truncation/race on delivery.
  2. 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)
  1. Identical input_tokens: 16255 across glitched spawns with different-length prompts — the failures correlate with a specific assembled-context/cache-split shape, not with prompt content.
  2. 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 and end_turns. Same trigger, different coin flip.
  3. Trigger hypothesis: the skill_listing attachment 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.
  4. 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

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗