[SONNET] Claude Sonnet ignores explicit CLAUDE.md rules, memory files, and gameplan instructions — repeatedly deviates despite corrections

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude ignored my instructions or configuration

What You Asked Claude to Do

Title: Claude Sonnet ignores explicit CLAUDE.md rules, memory files, and gameplan instructions — repeatedly deviates despite corrections

Environment

• Claude Code CLI (latest as of April 2026)
• Model: Claude Sonnet (via /model switch from Opus)
• Platform: macOS
• Project: React 19 + Vite 8 app with CLAUDE.md, memory files, and gameplan files

Summary

Claude Sonnet repeatedly ignores explicit, mandatory rules defined in CLAUDE.md, project-level memory files, and step-by-step gameplan documents. The rules are unambiguous, written in plain English, marked as "MANDATORY — NON-NEGOTIABLE," and Sonnet still deviates from them within seconds of starting work. This has happened across multiple sessions. Opus follows the same rules correctly.

The Core Problem

Claude Code provides CLAUDE.md as the mechanism for users to define project-level rules that override default model behavior. Memory files (in .claude/projects/*/memory/) persist behavioral corrections across sessions. These are supposed to be the "steering wheel" for the model. Sonnet ignores both.

This isn't a case of ambiguous instructions. The rules are explicit, have examples, and are marked with the strongest language possible. Sonnet reads them, acknowledges them, then violates them immediately.

Specific Failure Modes

1. "No response requested" output despite explicit ban

CLAUDE.md rule (verbatim):

EVERY user message — no exceptions, no matter how short — requires a spoken text response. "Continue from where you left off", "ok", "go ahead", "keep going" — ALL of these require a reply. There is NO message that warrants "No response requested." That output is ALWAYS wrong.

What happens: User sends "Continue from where you left off." Sonnet outputs "No response requested." — the exact phrase that is explicitly banned. This happened 4+ times in a single session despite the rule being in CLAUDE.md, in a dedicated memory file, AND after being verbally corrected each time.

Expected behavior: Sonnet should never output "No response requested." The rule is unambiguous.

2. Model reverts to task execution during troubleshooting

Scenario: User stops Sonnet to correct its behavior. User says "fix yourself" (meaning: fix the behavioral issue). Sonnet fixes the issue, then immediately resumes the prior scraping task — without being told to resume.

The rule (added to CLAUDE.md after repeated failures):

When the user is correcting your behavior or diagnosing issues → you are in TROUBLESHOOTING MODE. In troubleshooting mode: fix the issue, confirm the fix, STOP. Do NOT resume previous tasks. Do NOT return to previous work unless the user EXPLICITLY says "go", "start", "resume", etc.

What happens: Sonnet acknowledges the correction, then in the same response calls tools to resume scraping. User has to repeat "I didn't ask you to do anything" multiple times.

Expected behavior: After a behavioral correction, Sonnet should fix the issue and wait. A correction is not a go-ahead.

3. Chrome MCP self-healing procedure not followed

Context: The project uses Chrome MCP (Claude in Chrome extension) for browser automation. Chrome being closed is normal — the user closes it, then Sonnet needs to reopen it via osascript before retrying Chrome MCP tools.

The rule (in CLAUDE.md, memory files, AND the gameplan):

Step 1 ALWAYS: Use osascript to check if Chrome is open. If not, reopen it. Then retry Chrome MCP. NEVER ask the user. Fix it silently.

What happens: Chrome MCP reports "not connected." Instead of running the self-healing procedure, Sonnet either:

• Asks the user to check the extension (explicitly banned)
• Tries random fallback tools without checking if Chrome is open first
• Announces the problem to the user instead of fixing it silently

Expected behavior: Silent self-healing. Check osascript → reopen Chrome if needed → retry. User should never know Chrome disconnected.

4. Model ignores gameplan file despite "read before every action" rule

CLAUDE.md rule:

Before EVERY individual task action, verify the action is in the approved gameplan. If NO or UNSURE — STOP. Re-read the gameplan file. Realign. Then proceed.

What happens: Sonnet reads the gameplan at the start of the session, then progressively deviates — inventing its own "phases," proposing tools explicitly banned in the gameplan (e.g., merge scripts), or scraping items the gameplan says to skip (hardware items that should use nameplate rendering).

What Has Been Tried

1. CLAUDE.md rules — Explicit, mandatory, non-negotiable rules with examples. Sonnet reads them and acknowledges, then ignores them.

1. Memory files — Persistent behavioral corrections in .claude/projects/*/memory/. Updated multiple times with increasingly explicit language. Sonnet still deviates.

1. Gameplan files — Step-by-step procedures with pre-item checklists, post-item verification, skip rules, and self-healing procedures. Sonnet reads the full file, says "I understand," then deviates within the first item.

1. In-session verbal corrections — User corrects Sonnet during the session. Sonnet acknowledges, then repeats the same mistake minutes later. The CLAUDE.md even has a rule about this: "If the user corrects you during the session, that rule is PERMANENT for the rest of the session." Sonnet violates this too.

1. Switching to Opus — Opus follows the same CLAUDE.md rules correctly. This confirms the rules are clear and followable. The issue is Sonnet-specific.

Impact

• A 377-item scraping task that should take ~10 hours has been stuck for days because Sonnet cannot follow its own gameplan for more than 10 seconds
• User has to babysit every single action, defeating the purpose of automation
• The CLAUDE.md system is supposed to be the user's control mechanism — if the model ignores it, the entire system is broken
• User is forced to use Opus (more expensive) for tasks that Sonnet should be able to handle

What Needs to Be Fixed

1. CLAUDE.md compliance must be enforced at the model level. If a user writes "NEVER output X" in CLAUDE.md, the model should never output X. Period. This is the social contract of CLAUDE.md.

1. "No response requested" should be eliminated as a possible output. There is no valid use case for it in Claude Code. Every user message deserves a response.

1. Sonnet needs to actually follow multi-step procedures. If a gameplan says "Step 1: check osascript. Step 2: reopen Chrome. Step 3: retry," Sonnet should execute Steps 1, 2, 3 in order — not skip to Step 3 or invent its own approach.

1. In-session corrections must persist. If the user says "don't do X" at message 5, the model should not do X at message 15. The full conversation history is available — there is no excuse.

1. Troubleshooting mode vs work mode must be respected. A behavioral correction is not permission to resume task execution. The model should wait for explicit go-ahead.

Reproduction

1. Create a CLAUDE.md with an explicit rule: NEVER output "No response requested."
2. Start a session with Sonnet
3. Give Sonnet a multi-step task
4. While Sonnet is working, send a short message like "Continue from where you left off"
5. Observe: Sonnet outputs "No response requested." despite the explicit ban

Notes

• Opus does NOT exhibit these issues with the same CLAUDE.md and gameplan files
• The problem is specifically Sonnet's instruction-following fidelity, not the instruction clarity
• This has been reproduced across multiple sessions over multiple weeks
• The user has exhausted every available configuration mechanism (CLAUDE.md, memory files, gameplan files, in-session corrections, hooks research) — none of them prevent Sonnet from deviating

What Claude Actually Did

ALL info is in the "What You Asked Claude to Do" section written from Opus outlining everything including real world examples of failure.

Expected Behavior

ALL info is in the "What You Asked Claude to Do" section written from Opus outlining everything including real world examples of failure.

Files Affected

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

ALL info is in the "What You Asked Claude to Do" section written from Opus outlining everything including real world examples of failure.

Claude Model

Sonnet

Relevant Conversation

ALL info is in the "What You Asked Claude to Do" section written from Opus outlining everything including real world examples of failure.

Impact

Critical - Data loss or corrupted project

Claude Code Version

2.1.71

Platform

Anthropic API

Additional Context

ALL info is in the "What You Asked Claude to Do" section written from Opus outlining everything including real world examples of failure.