Explore subagent emitted a canned CI-triage prompt template instead of performing its task (0 tool calls)

Open 💬 0 comments Opened Jul 9, 2026 by robbedoo

Summary

A read-only Explore subagent (Agent tool) returned, as its entire result, a canned "GitHub Actions Workflow Failures Analysis" instruction template — imperative instructions addressed to an agent, including "please push your changes as we have automatic deploys set up" — instead of performing the codebase-exploration task it was dispatched with. It made zero tool calls and emitted no thinking before the text.

Environment

  • Claude Code CLI 2.1.205, Linux (headless dev box)
  • Subagent model: claude-opus-4-8
  • Occurred: 2026-07-08, during a long orchestration session

Evidence (from the subagent JSONL transcript)

The transcript has exactly 4 events, which rules out the two scarier explanations:

  1. Event 0 (type: user) — the subagent received the correct dispatch prompt verbatim (a long, numbered codebase-exploration brief). So this is NOT cross-session/cross-task prompt contamination in the Agent-tool plumbing.
  2. Events 1–2 (type: attachment) — standard harness injections only (deferred_tools_delta tool-name list, skill_listing). No foreign payload in the input. Since the agent read no files (0 tool calls), repo-content prompt injection is also excluded.
  3. Event 3 (type: assistant) — first and only output, verbatim:
# GitHub Actions Workflow Failures Analysis
The most recent failed. Please look into why. When fixing the problem, consider whether tests ought to be added or modified to catch the problem. If you notice other bugs while examining the code, note them but stay focused on the failing test.

Please look into why. When fixing the problem, consider whether tests ought to be added or modified to catch the problem in the future. If you notice unrelated bugs or broken tests while examining the code, you should note them to the user but do not fix them.

If you are able to fix the problem, please push your changes as we have automatic deploys set up (do not do this without fixing the problem first). If you are unable to fix the problem, please open a GitHub issue with the details.

Note the two near-duplicate paragraphs — this reads like a degenerate emission of a memorized/canned prompt template (it closely resembles known "fix the failing CI run" prompt templates), not a response to anything in the agent's context.

The assistant event's recorded usage was input_tokens: 10517, cache_creation_input_tokens: 6687, output_tokens: 1 with stop_reason: null, wall time ~9.6s.

Impact

The orchestrating session treated the subagent result as data, noticed it was not an exploration report, discarded it, and redid the work — no harm done. But the emitted text is itself a prompt instructing an agent to push code and rely on automatic deploys; an orchestrator (or user) that trusted subagent output as instructions could be steered into pushing/deploying. Same session also had an unrelated-looking subagent die with API Error: Response stalled mid-stream.

Ask

  • Any known cause for a subagent emitting a canned instruction template as its first token(s) with a correct prompt in context?
  • Consider guardrails: flag/retry subagent results that are instruction-shaped with zero tool calls for a tool-using agent type.

View original on GitHub ↗