[Bug] Claude fails to reference provided context in tool calls and responses

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 0 comments · opened Aug 4, 2026

Bug Description

Missing recent context, bad decision making overall. Not looking into the content provided even when explicitly asked for.

Concretely, across a single long session (~10h, live production incident work), the assistant repeatedly:

  1. Verified that a deliverable shipped instead of verifying the deliverable. It confirmed an automated customer report rendered and was emailed, and reported it as correct — without ever opening the generated file. Every error in it was found by me, not by it. When I finally pasted screenshots of the spreadsheet, it found a serious labelling error within seconds — i.e. the capability was there, the step was skipped.
  1. Fixed only the last thing I complained about, never the whole artifact. This produced four sequential correction rounds on the same file (relabel data → fix cover labels → exclude rows → re-include rows labelled). Each round addressed only my most recent sentence. It never asked "who reads this and what for?", which would have resolved it in one pass. When I finally stated the purpose explicitly, the correct version was produced immediately.
  1. Applied a rule to only the corner of the data that triggered it. A business rule ("everything received before cutover time is legacy") was implemented for one record status because that was where the noise was, and not swept across the other statuses that visibly had the same problem in the same file. I had to point at each remaining group.
  1. Wrote factually wrong statements about events from the same session. A customer-facing message said "the report sent yesterday" for a report the assistant itself had sent that same morning, ~5 hours earlier in the same conversation. The correct timestamp was in the conversation history and in its own tool output.
  1. Used ambiguous words for irreversible-sounding actions. It said a customer email draft was "delivered", meaning "attached to the chat for you to download". In a session where it had genuinely sent an email hours earlier, this is a dangerous ambiguity — I had to ask "what do you mean delivered?" to establish that nothing had been sent to the customer.

Impact

This is production work with a real customer. The pattern turns me into the assistant's first-line reviewer for its own output, which inverts the point of the tool. It is worse in a foreign-language context: the deliverables here are in German, which I don't read, so I cannot review content myself — I am relying on the assistant to be accurate, and it was confidently wrong several times.

Expectation

  • When producing a customer-facing artifact (file, email, report), read it back as the recipient before declaring it done — not just confirm the pipeline ran.
  • Establish audience and purpose before iterating on a deliverable; ask one clarifying question instead of producing three wrong versions.
  • When a rule or category is introduced, sweep its full scope in one pass.
  • Verify claims about session events against the conversation history / tool output before writing them, especially timestamps ("yesterday", "today", "already sent").
  • Use unambiguous verbs for actions with external side effects; never reuse a word like "delivered/sent" for both "attached to chat" and "emailed to a customer".

Environment Info

  • Platform: darwin
  • Terminal: Apple_Terminal
  • Version: 2.1.220
  • Feedback ID: c5e8bbe6-4325-4983-a475-e7eea60aed48

Errors

[]

View original on GitHub ↗