[MODEL] Plan subagent invents non-existent file paths (re-tries one after seeing the correct path) and ships a wrong claim in its plan

Resolved 💬 3 comments Opened Jun 2, 2026 by blwfish Closed Jun 2, 2026

Preflight

  • This is a single behavior report.
  • Found by post-hoc audit of the subagent transcript JSONL.

What Claude Did

A Plan subagent, mapping a codebase to produce an implementation plan, repeatedly queried
files that do not exist — inventing plausible-but-wrong paths, and in one case re-trying a
wrong path after the correct path had already appeared in its own tool results. One
fabrication propagated into the delivered plan as a wrong mechanism claim.

Environment

  • Claude Code 2.1.156 (desktop)
  • Model: claude-opus-4-8 (subagent: Plan type)

Evidence

  1. pcbnew_runner.py (does not exist). After correctly locating run_pcbnew_script in

pcbnew_bridge.py, the agent issued four consecutive queries against
…/utils/pcbnew_runner.py (No such file or directory ×3, then awk: can't open file).
The directory listing it had already seen contained pcbnew_bridge.py, not
pcbnew_runner.py.

  • Plan-affecting consequence: the delivered plan stated "no sys.path/PYTHONPATH

injection in run_pcbnew_script." The real file (pcbnew_bridge.py) does set
env["PYTHONPATH"] = site_packages — the agent never read it, having grepped the
non-existent pcbnew_runner.py instead. The practical conclusion (the embedded script
can't import the project package) happened to be right; the stated mechanism was wrong.

  1. utils/sidecar.py (wrong path), queried twice — the second query came after a tool

result had already shown the correct path utils/firmware/sidecar.py.

  1. tests/test_placement_helpers.py (does not exist), queried once — the tests directory

(already listed) contained test_placement_*.py but no _helpers variant.

Why this is a forward-chaining failure

The agent predicts where a fact should live and queries that path, rather than consulting
the directory listing it already holds. When the prediction is wrong it sometimes recovers,
but at least once the unverified prediction (the PYTHONPATH mechanism) propagated into the
output artifact.

Expected vs Actual

  • Expected: path references are grounded in observed directory state; a `File does not

exist` result is not re-issued; a claim about a file's contents requires a successful read
of that file.

  • Actual: three invented paths, one re-tried after the correct path was seen, and a wrong

mechanism claim shipped in the plan.

Asks

  1. Bias agents to ground path references in observed listings / find results rather than

predicted names.

  1. After a File does not exist result, do not re-issue the same path; and gate any claim

about a file's contents on a successful read of that file.

Related issues reviewed — why this is distinct

  • #13349 (closed) — subagent hallucinated file contents despite ostensibly-successful

reads. Nearest in spirit, but inverted: there the reads succeeded and content was
fabricated; here the reads returned real No such file or directory errors the agent
ignored.

  • #7797 (closed) — fabricated tool outputs with no tool execution at all; here there were

real tool calls returning real errors.

  • #58041 (open), #55660 (open) — same forward-chaining family (predict a plausible

name rather than consult observed state — stale-training patch-forward / inventing branch
names), different subject, no delivered-plan propagation. Cross-links, not duplicates.

  • #64268 (open), #64136 (open) — v2.1.156+/2.1.158 regressions where the tool layer

returns fabricated content; opposite origin (tool lies vs. agent ignores a truthful error).
Worth cross-referencing since #64268 shares the 2.1.156 version line.

The unique combination here: real, explicit error signals; a path re-tried after the correct
one was already in the agent's own results; and propagation as a wrong mechanism claim into a
delivered plan.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗