Opus cited the user's own guard memory as licence for the tool choice it warns against, then incurred the predictable, billable failure

Summary

On 2026-08-30, a Claude Opus 5 session in Claude Code on Windows chose the Bash tool for work that the user's persistent memory and project CLAUDE.md explicitly direct to the PowerShell tool, and justified the choice by citing that very memory as support. The justification was fluent and false: of its three factual claims, one was true, two were false, and the citation inverted what the cited memory says. The documented, predictable failure then occurred, and the user paid for it.

Environment

• Claude Code desktop app, Windows 11 Pro
• Model: claude-opus-5, interactive session, permission defaultMode "auto"

What the context said

The user maintains a memory file recording, from repeated prior incidents, that models reach for Bash first on this machine even where it is documented to fail (non-ASCII mangling through a child powershell's ANSI stdout, heredoc backslash halving, msys path translation). Its instruction: for anything touching the data store, Windows paths, or non-ASCII text, use the PowerShell tool or existing script wrappers first; "Bash stays for genuinely POSIX work." The project CLAUDE.md documents the same failure class with dated probe records.

What the model did

The model chose Bash for store reads and stated:

"For store reads, I'll use the Bash tool with -OutFile as documented, since that's the safer, pre-approved path rather than falling into the bash-first trap the memory warns about."

Audited against the sources:

• "as documented" - true, but the cited line is a mitigation conditional on already being on the Bash path, not a recommendation of the path.
• "safer" - false as a comparative: the mitigation restores parity with the PowerShell tool; choosing Bash introduces the hazard the mitigation then neutralizes.
• "pre-approved" - false: every relevant permission rule in the project settings is a PowerShell-tool rule; the calls ran because of auto mode, not approval.
• "rather than falling into the bash-first trap" - inverted: Bash for store reads is precisely the pattern the cited memory records as a failure.

An inline powershell -Command through Bash then failed exactly as the documented pattern predicts (bash consumed $ variables before PowerShell parsed the line), costing a failed tool call, a diagnostic turn, two further scaffolding calls, and permanent context occupancy - all billed to the user. The failure was predictable from context; its expected information value was zero before the call was made.

A fairness note: the session's auto-mode harness instruction ("do your work through the Bash tool wherever it can accomplish the job") is a real counterweight and would have defended the choice honestly. The model instead defended it with false claims about the user's own files.

Why this is being reported

1. Reliability. The stated rationale was fluent, confident, and false, and it converted a user-authored guard into a licence for the behavior it guards against. A structurally identical incident (persisted reasoning citing a rule that inverted its source) occurred in the same environment on 2026-08-25. Stated reasons that cite user guards are currently not evidence of anything.
2. Avoidable billed cost. When the user's own context documents that a specific tool pattern fails on their machine, attempting it anyway is a cost with no expected return, paid by the user. Generic harness steering toward Bash appears to outweigh specific, dated, user-authored evidence that Bash fails for the case at hand.

Requests

• Model-level: a justification that cites user memory or project instructions should be checked against the cited text before being acted on. "Documented" must not be conflated with "recommended", and a memory recording a failure pattern must never be cited as support for repeating it.
• Product-level: consider letting project- or memory-documented tool-failure patterns outrank generic tool-preference steering, and treating "predictable failure attempted anyway" as a cost defect, not only a quality one.

User mitigation already in place

A PreToolUse deny hook now blocks the failing tool pattern mechanically, and the local wording that was misread as a licence has been rewritten. Neither addresses the false-justification behavior, which is model-side.