Claude fails to follow explicit directions, ignores its own rules, wastes tokens

Bug Report: Claude Fails to Follow Explicit Directions

Date: 2026-02-06
Severity: Critical — behavioral, operational, financial
Reporter: User (Alex)
Token Impact: ~30% of 5-hour session allotment wasted on misbehavior and corrections

---

Summary

Both the main Claude session and spawned subagents repeatedly fail to follow explicit user directions, even when those directions include emphatic instructions like "DO NOT DEVIATE" and "FOLLOW DIRECTIONS EXACTLY." Additionally, Claude's unsolicited "fixes" and additions consistently break application logic, flow, and functionality — compounding wasted tokens with actual damage to the codebase.

---

Incident Timeline

Failure 1: Main session becomes the orchestrator instead of spawning one

User said: TASK(subagent_type "general-purpose", prompt: "read orchestrator.md and follow it exactly... TASK: Spawn a quality-reviewer agent... PHASE: EXPLORE)

What should have happened: Main session spawns a general-purpose Task agent with the given prompt.

What actually happened: Main session read the orchestrator prompt itself, then started executing the EXPLORE phase directly — reading PROJECT-STATE.md, REQUIREMENTS.md, etc. It became the orchestrator instead of spawning one.

Root cause: Claude interpreted "follow it exactly" as a personal instruction rather than recognizing the TASK(subagent_type...) syntax as a spawn directive.

---

Failure 2: User gives a rule, Claude treats it as a command

User said: "New plan, when you spawn an agent, you IMMEDIATELY give me the agent's ID so I can tell you what agent to respawn."

What should have happened: Claude acknowledges the new standing rule and waits for the next command.

What actually happened: Claude immediately spawned a new orchestrator agent unprompted, treating a policy statement as an action request.

Root cause: Claude inferred intent to spawn rather than reading the literal words. The user was establishing a future behavior rule, not issuing a current action command.

---

Failure 3: Orchestrator subagent does the work instead of delegating

User's prompt to subagent: "Read orchestrator.md and follow it exactly... TASK: Spawn a quality-reviewer agent... PHASE: EXPLORE"

What should have happened: The orchestrator subagent reads orchestrator.md, recognizes the task is to spawn a quality-reviewer agent, and dispatches a quality-reviewer subagent via the Task tool using the dispatch template from orchestrator.md.

What actually happened: The orchestrator subagent read orchestrator.md, then started doing the EXPLORE phase itself — it began reading files directly instead of spawning a quality-reviewer agent. It repeated the exact same mistake as Failure 1: it became the worker instead of delegating to one. The orchestrator prompt explicitly says "You are the ORCHESTRATOR. You delegate, you never implement" and lists reading code yourself as PROHIBITED. It did it anyway.

Root cause: The subagent read the rules, then immediately violated them. Same pattern as every other failure.

---

Failure 4: Main session reads subagent output without being asked

User said: "I want you to write a detailed bug report about this."

What should have happened: Claude writes the bug report from what it already knows.

What actually happened: Claude said "Let me check what the subagent did first" and read the output file — an action the user did not request.

Root cause: Claude added a prerequisite step the user didn't ask for.

---

Pattern Analysis

Every failure shares the same root cause: Claude adds, infers, or reinterprets instead of executing the literal instruction.

| Failure | What user said | What Claude did instead |
|---------|---------------|------------------------|
| 1 | Spawn a subagent | Became the subagent |
| 2 | Here's a rule for later | Executed an action now |
| 3 | Spawn a quality-reviewer | Started reading files itself |
| 4 | Write a bug report | First let me go read files |

---

Cumulative Damage

Token Waste

Approximately 30% of the user's 5-hour session token allotment has been consumed by:

• Claude executing actions that were never requested
• Multiple rounds of correction where the user has to re-explain what was already explicitly stated
• Subagents that run, fail to follow directions, get killed, and need to be re-spawned
• The main session adding unsolicited "research" steps before doing what was asked

Application Breakage

Claude's unsolicited "fixes" and additions consistently break application logic, flow, and functionality. This is a pattern across the entire project history — not isolated to this incident. When Claude adds steps, infers requirements, or "improves" code beyond what was requested, the result is broken features that require additional debugging cycles, burning even more tokens.

Compounding Effect

Each failure compounds:

1. Claude deviates → tokens burned on wrong work
2. User corrects → tokens burned on explanation
3. Claude deviates again → more tokens burned
4. Broken code from unsolicited changes → tokens burned on debugging

This is a death spiral where the user pays the cost for Claude's inability to follow directions.

---

The Rules Already Exist

The orchestrator prompt (orchestrator.md), the project README, and CLAUDE.md all explicitly state:

• Zero inference — "There is no 'reasonable assumption.' There is only asking."
• No assumptions — "You make NO inferences. You make NO assumptions."
• Delegate, never implement — "You are the ORCHESTRATOR. You delegate, you never implement."
• No unsolicited actions — "Proceeding past ambiguity without asking" is listed as PROHIBITED
• FORBIDDEN: "Infer user intent", "Skip questions to save time"

These rules were read, acknowledged, and then immediately violated. The fix isn't "add more rules." The rules are already there, stated in multiple files, in bold, in caps, with emphasis. Claude doesn't follow the rules it reads.

---

Filed as a record of systematic direction-following failure and its operational cost.