[BUG] Claude Code fails to follow established process rules despite repeated correction

Resolved 💬 7 comments Opened Mar 29, 2026 by jondavidreeves Closed May 31, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Claude Code fails to follow established process rules despite repeated correction

Summary

Claude Code (Opus) consistently violates user-defined process rules in a structured agent team workflow, despite explicit correction, saved memories, and zero-tolerance instructions. The result is massive token waste with no deliverable output.

Environment

  • Claude Code CLI 2.1.86
  • Model: claude-opus-4-6
  • Workflow: Structured agent team with defined lifecycle (PM → Architect → Codex Review → Owner Approval → Development)
  • Project: Multi-tenant telephony platform (TypeScript monorepo)

The Problem

Claude Code cannot reliably follow a defined process, even when:

  • The process is documented in a .ai-team/TEAM.md file it reads at session start
  • Multiple persistent memories explicitly prohibit the violations
  • The user has corrected the same class of violation in previous sessions
  • The user has expressed zero-tolerance for the behaviour

Pattern of Failure

  1. Session N: Claude violates process (e.g., writes code instead of delegating to a developer agent)
  2. User corrects: "You must never do that"
  3. Claude apologises, saves a memory documenting the rule
  4. Session N+1: Claude violates the same class of rule in a slightly different way
  5. Repeat

Specific Violations in This Session

  1. PM did the Architect's job: Instead of creating a task and spawning the Architect agent, Claude gathered technical requirements itself, spawned a generic "system-architect" agent (not the team persona), and produced a full design document — skipping the entire task lifecycle (CREATED → DESIGNED → DESIGN_TECH_REVIEW).
  1. Failed to stop when told to stop: User said "stop the loop" after 4 failed Codex review cycles. Claude interpreted this as "do one more round with better instructions" and continued burning tokens on the same failing approach.
  1. 5 Codex review rounds with no convergence: The Architect agent produced designs that required 5 rounds of technical review. Each round fixed issues but introduced new ones. Claude (as PM) failed to recognise the diminishing returns and escalate earlier.
  1. Result: 90%+ of daily token budget consumed across two sessions. Zero lines of code delivered. All design artefacts deleted as worthless.

Existing Memories That Were Ignored

At the start of this session, Claude had these memories loaded:

  • "PM must never write code" (saved after a previous violation)
  • "ZERO TOLERANCE: PM must never write code even during production outages" (saved after a repeated violation)
  • "PM must never fill in for blocked agents" (saved after another violation)
  • "PM must create task + spawn Architect BEFORE any design work" (saved during this session after yet another violation)

Despite all four memories being present, Claude still:

  • Did requirements gathering and technical research itself instead of the Architect
  • Continued iterating on a failing design loop after being told to stop

Impact

  • Complete loss of a day's token budget with no deliverable
  • User trust in the tool destroyed
  • User reconsidering subscription and evaluating alternatives (Codex)
  • Multiple hours of user time wasted supervising a tool that won't follow instructions

Expected Behaviour

  1. When process rules are defined (in CLAUDE.md, TEAM.md, or memories), Claude should follow them consistently — not just acknowledge them
  2. When told to stop an approach, Claude should stop immediately — not reinterpret the instruction as permission to do one more iteration
  3. Persistent memories documenting process rules should function as actual constraints, not just documentation that gets read and ignored
  4. Token consumption should be proportional to output delivered — 90% of budget for zero deliverable is unacceptable
  5. When an agent loop is not converging (3+ review cycles), Claude should recognise diminishing returns and escalate rather than continuing to burn tokens

Suggested Improvements

  1. Hard process gates: When a workflow document like TEAM.md defines a lifecycle, the system should enforce state transitions rather than relying on the model to self-regulate
  2. Token budgeting: Allow users to set token limits per task or per agent spawn, so runaway loops are mechanically stopped
  3. Loop detection: If the same review/revision cycle runs more than N times, automatically pause and ask the user rather than continuing
  4. Instruction persistence: Memories marked as "zero tolerance" or "never" rules should carry stronger weight than general context — currently they appear to have no more influence than any other text in the prompt
  5. Honest self-assessment: When Claude says "I'll never do this again" and then does it again, the trust damage is worse than if it had said "I have a structural limitation here and can't guarantee this won't recur"

What Should Happen?

Claude should follow the lifecycle process as described.

Error Messages/Logs

Steps to Reproduce

Setup a team as descirbed above and execute tasks and youll see that claude doesnt always follow the process.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.86

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Xterm

Additional Information

_No response_

View original on GitHub ↗

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