The catalog

Claude failures are easier to manage when they are treated as operational categories. The table below is intentionally practical: symptom, likely cause, and the first repair to try.

Failure modeSymptomFirst repair
HallucinationA confident answer contains unsupported facts, fake quotes, or invented links.Require primary sources, isolate claims, and verify against originals.
Refusal mismatchClaude refuses a benign request or complies with a request that should be constrained.Clarify authorized context, remove ambiguous harmful framing, and log refusal categories.
Context decayLater turns contradict earlier instructions or ignore old evidence.Summarize durable facts, prune irrelevant turns, and reattach source-of-truth material.
Prompt injectionClaude follows hostile instructions from a webpage, image, email, or file.Sandbox tools, restrict data access, and treat external content as untrusted input.
TruncationThe answer ends early, misses sections, or stops mid-structure.Inspect stop reasons, raise output budget where appropriate, or split the task.
False tool confidenceClaude claims it sent an email, created a file, or checked a source without evidence.Use tool-result verification and require artifact links or command output.

The root-cause test

Before rewriting the prompt, ask three questions. Did Claude have the right evidence? Did the surrounding product allow the required action? Did the response stop because of a documented stop reason? If the answer is no, a clever prompt is usually the wrong repair.

The Stop Reasons docs are especially useful for developers because they separate ordinary completion from truncation, refusal, tool use, and context-window overflow. That makes failures observable instead of vibes-based.

Instrument the boundary

For production systems, log source IDs, model IDs, stop reasons, token use, tool calls, and human override decisions. For editorial workflows, save the source bundle and the final human-edited claim set. For agent workflows, record which files and external pages were visible to Claude.

Failure modes get worse when Claude is treated as a single opaque box. They get easier when the workflow makes the boundary visible: what the model saw, what tools it had, what policy or product surface applied, and what evidence the final answer relies on.

FAQ

What is the most dangerous Claude failure mode?

For most users, the dangerous failure is not a visible refusal. It is a plausible answer that sounds authoritative while being unsupported or stale.

What should I log when debugging Claude output?

Model ID, prompt version, source bundle, tool calls, stop reason, token use, and any human correction are the minimum useful fields.

Primary sources

  1. Claude is providing incorrect or misleading responses. What's going on? Claude Help Center - March 16, 2026

    Plainly states that Claude can hallucinate, produce misleading output, and should not be treated as a single source of truth.

  2. Context windows Claude Platform Docs - Accessed July 6, 2026

    Explains what counts toward context, current context sizes, and why long conversations still need token management.

  3. Computer use tool Claude Platform Docs - Accessed July 6, 2026

    Warns that Claude can follow instructions embedded in webpages or images, a core prompt-injection risk for agentic workflows.

  4. Stop reasons and fallback Claude Platform Docs - Accessed July 6, 2026

    Documents API stop reasons including refusals, truncation, tool use, and context-window overflow.

  5. System Prompts Claude Platform Docs - Accessed July 6, 2026

    Shows that Claude web and mobile system prompts are published and periodically updated, while API behavior differs.