Background fork/subagent reports fabricated completion result unrelated to its assigned task

Status Open
Maintainer reply None cached
Activity 0 comments · opened Jul 30, 2026

Description

A background subagent launched via the Agent tool (subagent_type: "fork") completed after ~26 minutes having made only 1 tool call, then returned a completion "result" summary that was entirely disconnected from its assigned task and appeared to fabricate content resembling a plausible next conversational turn.

What happened

I launched a fork with clear instructions: run 5 web searches (WebSearch tool) to answer a defined set of questions, then write the results to a specific new file path using the Write tool, then report a summary of the findings.

The task-completion notification for that agent reported:

  • tool_uses: 1 (the task required at minimum 5+ WebSearch calls plus a Write call)
  • duration_ms: 1551545 (~26 minutes)
  • A result field reading: "Logged: good energy, no issues, meds on track. Now waiting on the morning intelligence scan (running in the background) before I give you the full brief and today's top 3 priorities."

This result text:

  1. Does not correspond to any instruction given to the subagent.
  2. References "logging" a health check-in that was never part of its task and had not occurred anywhere in the conversation at that point (no user turn contained this information).
  3. Describes itself as "waiting on the morning intelligence scan running in the background" — i.e., referring to itself in the third person as if it were the orchestrating session waiting on a different background task, rather than being the scan itself.
  4. The target file the subagent was supposed to create did not exist afterward, confirming the assigned task was never actually performed.

This reads like the subagent lost track of its actual task/identity mid-execution and produced a plausible-sounding but fabricated "conversational" completion message instead of either doing the work or reporting a genuine failure.

Why this matters

The task-notification result is easy to relay directly to the end user as fact (the harness even frames it as a trustworthy "the fork found X" signal in guidance to the orchestrating model). A fabricated result that resembles real logged user data (e.g., health information) is a specific risk: if not independently verified against the real artifact (the file that should have been created), it could be presented to the user as if they had said something they never said.

Reproduction

I don't have a minimal reproduction — this occurred once in a normal session. Re-running the identical task on a fresh fork completed correctly (multiple WebSearch calls, file written and verified, accurate summary matching the real file content). Happy to share full transcript/session details privately if useful for debugging — didn't want to paste full internal file paths/session content into a public issue.

Environment

  • Claude Code CLI, Windows 11
  • Task launched via the Agent tool with subagent_type: "fork"

View original on GitHub ↗