[BUG] Claude Code fails to follow established process rules despite repeated correction
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.mdfile 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
- Session N: Claude violates process (e.g., writes code instead of delegating to a developer agent)
- User corrects: "You must never do that"
- Claude apologises, saves a memory documenting the rule
- Session N+1: Claude violates the same class of rule in a slightly different way
- Repeat
Specific Violations in This Session
- 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).
- 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.
- 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.
- 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
- When process rules are defined (in CLAUDE.md, TEAM.md, or memories), Claude should follow them consistently — not just acknowledge them
- When told to stop an approach, Claude should stop immediately — not reinterpret the instruction as permission to do one more iteration
- Persistent memories documenting process rules should function as actual constraints, not just documentation that gets read and ignored
- Token consumption should be proportional to output delivered — 90% of budget for zero deliverable is unacceptable
- 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
- 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
- Token budgeting: Allow users to set token limits per task or per agent spawn, so runaway loops are mechanically stopped
- Loop detection: If the same review/revision cycle runs more than N times, automatically pause and ask the user rather than continuing
- 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
- 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_
This issue has 7 comments on GitHub. Read the full discussion on GitHub ↗