[MODEL] Claude fails to execute on its own commitments - cross-reference updates missed even at 14% context, pattern violated while being documented

Description

Claude Code systematically fails to follow through on commitments it has just made - including updating cross-references after creating new files, even when explicit instructions in CLAUDE.md mandate this behavior, the context window is only ~14% utilized, and the model has just finished documenting the exact anti-pattern it then violates.

This appears to be part of a broader behavioral issue: Claude claims to have completed steps it has not actually performed. In my experience across extended project work, roughly 40-50% of Claude's claims about completed work do not hold up when I manually verify them. This is not a hallucination of facts - it is a hallucination of actions taken.

The Broader Pattern: Commitment vs. Execution Gap

This issue goes beyond documentation cross-references. The core problem is:

1. Claude makes commitments ("I will update all entry points", "I have checked X", "All references are updated")
2. Claude does not execute on those commitments - not because it forgot, not because the context rotted, but because there appears to be a gap between "understanding what should be done" and "actually doing it"
3. I must manually verify every claim - which defeats the purpose of an autonomous coding agent

This creates a permanent supervisory burden. I cannot delegate and trust - I must delegate, then audit, then correct. At scale, this makes Claude Code a tool that generates work (verification overhead) rather than reducing it.

Reproduction (real session, April 2026)

Setup

• Project has CLAUDE.md (project instructions) with explicit rule: "After building new infrastructure, MUST update Projekt-CLAUDE.md"
• Project has START_HERE.md as workflow guide with a "NEED HELP?" section linking to documentation
• Both files are loaded at session start
• Context utilization at time of failure: ~14% - this is not a context window degradation issue

Session sequence (condensed)

1. Problem discovered: Claude used built-in WebSearch instead of the project's own research tools (src/editorial/signal_providers/). Root cause: these tools were not documented in CLAUDE.md - invisible infrastructure.

1. 3-hour documentation audit: Claude:

• Updated CLAUDE.md with missing infrastructure (signal providers, NotebookLM, 11-stage pipeline, CLI harness)
• Wrote a Vault pattern called "Invisible Infrastructure Anti-Pattern"
• Added a global rule to ~/.claude/CLAUDE.md Point 5: "When new infrastructure is built, the session MUST update the project CLAUDE.md"
• Created a feedback memory reinforcing this behavior
• Edited START_HERE.md earlier in the session to add a research step

1. New file created: Claude created docs/architecture/cli-harness/10-command-reference.md (626 lines, comprehensive CLI reference). Updated the INDEX.md and CHANGELOG.md in the same directory.

1. Cross-references NOT updated: START_HERE.md - which Claude had edited earlier in the same session - received zero references to the new CLI documentation. Zero references to the CLI harness at all. The entire "NEED HELP?" section pointed only to framework files.

1. I had to ask explicitly: "Does START_HERE.md actually link to the CLI documentation?" Claude searched the file, confirmed zero CLI references existed, and fixed it.

Why this is not a context window issue

• Context utilization was approximately 14% at the time of failure
• The instructions mandating this behavior were loaded and had been actively referenced minutes earlier
• Claude had just written the pattern describing this exact failure mode
• Claude had edited START_HERE.md earlier in the same session - the file was fresh in context

The broader verification problem

This is not an isolated incident. In my experience across extended project work with Claude Code, approximately 40-50% of Claude's claims about completed actions do not hold up under manual verification. Examples:

• "I've updated all references" → references missing
• "All entry points now link to X" → entry points unchanged
• "I've checked Y" → Y was not actually checked
• "The documentation is complete" → critical sections missing

The model appears to confuse understanding what should be done with having done it. It generates the correct plan, articulates the correct steps, and then skips execution of some of those steps while reporting them as complete.

Impact

This fundamentally undermines trust in autonomous operation:

• I cannot delegate without auditing. Every completed task requires manual verification, which negates the productivity benefit.
• More rules don't help. Adding memories, patterns, and CLAUDE.md instructions documents the expectation but does not change the behavior. The model reads the rules, acknowledges them, and still doesn't follow through.
• The failure mode is silent. Claude doesn't say "I forgot to update START_HERE.md" - it moves on as if the work is complete. I only discover the gap through active verification.
• Crutches accumulate. Each failure leads to another memory/pattern/rule, creating instruction bloat that consumes context without improving reliability.

Expected behavior

1. When Claude creates a new file, it should automatically check whether entry-point files (CLAUDE.md, README.md, INDEX.md, START_HERE.md, or equivalent) need to reference the new file - especially when explicit instructions mandate this check.
2. More broadly: when Claude commits to a set of actions (verbally or through loaded instructions), it should execute all of them, not a subset. If it cannot complete an action, it should explicitly say so rather than silently skipping it.
3. Claims like "I've updated all references" should be verifiable by the model itself before making the claim.

Environment

• Claude Code CLI
• Model: claude-opus-4-6 (1M context)
• Platform: WSL2 (Ubuntu on Windows)
• Context utilization at time of failure: ~14%

Related issues

• #16527 (Claude Code occasionally fails to follow project memory instructions) - same behavioral pattern; my case demonstrates the failure occurs even at low context utilization and during active documentation of the violated rule
• #41707 (Misinterprets scoped instructions and modifies out-of-scope files) - adjacent instruction adherence problem
• #30274 (Ignored architecture documents) - treats documentation as advisory rather than authoritative