Why AI Ignores Rules: Checking CLAUDE.md, Cursor Rules, and AGENTS.md

You ask Claude Code whether it has read CLAUDE.md. It says yes, but still skips the tests you specified. When this happens, distinguish between instructions that never reached the model and instructions that reached it but were not followed. The reply “I read it” does not establish either one.

For Cursor’s .cursor/rules, GitHub Copilot’s .github/copilot-instructions.md, and Codex CLI’s AGENTS.md, you also need to check where files are loaded from and when they apply. How a tool loads instructions and whether a model follows them are separate questions.

This article covers five things to check, including loading, restoration after compaction, and conflicting instructions, with a troubleshooting sequence and practical improvements. Shorter prose alone cannot guarantee compliance. Move conditions that can be checked mechanically into Hooks or CI, and keep questions requiring human judgment in review.

1. Why AI ignores rules: five things to check

1. Confusing length guidance with loading limits

Long instructions consume context and make important conditions harder to find. Claude Code’s documentation recommends keeping each CLAUDE.md file under 200 lines, but this does not mean loading stops at line 200. Distinguish a loading limit from compliance with loaded instructions. The documentation does not establish boundaries such as “150 lines guarantees compliance” or “the middle disappears above 200 lines.”

2. Auto-compact in long sessions

Claude Code’s /compact compresses the conversation, but the project-root CLAUDE.md is reloaded from disk and reinserted into context after compaction. In contrast, CLAUDE.md files in subdirectories and path-specific rules are reloaded when the relevant files are read. Distinguish decisions made only in chat, nested instructions that have not yet been reloaded, and instructions that were loaded but not followed.

3. Conflicting instructions and scope

If “test before committing” and “skip tests this time” coexist, the agent must determine which instruction applies. Chronology alone does not explain priority: newer does not simply mean higher priority. Compare project-wide, personal, and directory-specific instructions, and specify who can authorize exceptions. Writing a prohibition in CLAUDE.md does not itself remove permission to perform the operation.

4. Vague or contradictory rules

With subjective or abstract instructions such as “write politely” or “handle this appropriately,” the AI supplies its own interpretation, which can differ from your expectations. Make the requirement verifiable: “write no more than three lines” or “when using the Slack API, use chat.postMessage,” for example.

5. Bloated or scattered rule files

An ordinary link from CLAUDE.md to SPEC.md does not necessarily load the entire linked file at startup. Claude Code expands @path imports at startup, but their contents also consume context. Splitting files for organization is different from loading them only when needed. If duplicate rules disagree, clarify the source of truth and their scope.

These distinctions follow the official Claude Code memory documentation, checked against the original on September 21, 2026. Read length recommendations separately from the explanation of what returns after compaction to avoid misdiagnosing the cause.

2. How to check whether rules are being followed

Start by checking the current situation. Ask the AI these questions and examine its responses:

Even if the AI says “I read it” or “I understand,” whether it applies the instructions is a separate question. Check both evidence of loading and the results of execution.

Four steps to isolate the cause

1. Check the entry point. In Claude Code, inspect Memory files in /context to check loading of CLAUDE.md and rules. Also check that the file is in the relevant directory and is not excluded by settings. Direct loading of AGENTS.md is an exception that may not appear in this list, so absence from the list alone does not prove it was not read.
2. Trigger the conditions for the rule. For path-specific rules, have the agent read a matching file. If it has not read that file since compaction, the rules may not yet have been reloaded. Record startup instructions separately from instructions loaded for particular work.
3. Try a small, harmless task. Have the agent edit a disposable sample under rules such as “name the target file before changing it” and “report the test command and exit code afterward.” Do not use deletion of production data or publishing as your test. If you put a secret test phrase in the question itself, the agent can answer without reading the instruction file, so that does not test loading.
4. Verify the result independently. Check for unexpected changes in the diff, confirm that reported tests actually ran, and examine whether enough items were checked. One successful trial does not guarantee every future operation. Record changed settings, the tool version, and target files, then recheck when conditions change.

For example, if the agent loaded “test before committing” but did not run the tests, moving the file alone will not address the cause. Specify which tests to run, and do not mark the commit step complete without their results. Requiring CI checks before merging also gives you evidence beyond the AI’s own report.

If the relevant CLAUDE.md is missing from the loading display, correct the startup location and settings before adding more emphasis to the prose. Revisit the specificity of instructions and the checking process if violations remain after loading is confirmed. This sequence avoids attributing every failure to “the AI forgot.”

3. Quick fixes to try in five minutes

1. Separate always-needed rules from details read on demand

Use Claude Code’s official recommendation of fewer than 200 lines as a starting point, but reduce duplication and unnecessary explanation instead of chasing a line count. For example:

• Essential rules (10–20 lines) → the top of CLAUDE.md
• Detailed service specifications → separate SPEC-xxx.md files
• History and background → the docs/ directory

After moving details to another file, state in the entry-point file what to read before each kind of task. If you import everything needed for every session, splitting files does not reduce startup context. Use path-specific rules or skills when you want conditional instructions loaded only as needed.

2. Add priority markers

Importance labels help people and AI understand intent. The labels themselves do not enforce execution. For example, define them as follows:

• CRITICAL: a violation could cause a production incident
• MUST: always required
• SHOULD: normally expected
• NICE TO HAVE: optional when time allows

“CRITICAL: destructive queries against the production database require prior approval” specifies the operation and the condition requiring approval. Actually blocking unauthorized operations also requires permission settings or checks before execution.

3. Re-emphasize rules in chat

At the start of a session, add “State the three most important rules before starting work.” This creates an opportunity to check understanding, but does not guarantee that tests will run. Verify the results afterward as well.

4. Include verification conditions in the plan

Include “check the rules” in your AI agent’s task tracking and make each step’s completion conditions visible. Ask for the command, exit code, and untested scope rather than just “tested.” A completion mark without supporting evidence still leaves the work unverified.

4. Longer-term safeguards: Hooks, reviews, and skills

Turn conditions that can be evaluated into scripts, and control operation permissions through settings. Hooks, CI, AI review, and skills serve different purposes. Calling all of them “automatic enforcement” hides the areas they do not check.

1. Enforce checks with Claude Code Hooks

Claude Code’s Hooks feature can run scripts before or after specific tool calls. It lets you build a mechanism where the system stops an operation even if the AI forgets the rule.

For example, a PreToolUse hook can:

• Detect dangerous commands (rm -rf, git push --force) before the Bash tool runs, then deny them
• Check the target file’s permissions or lock status before the Edit tool runs
• Run project-specific tests before a commit and block it if they fail

When a PreToolUse hook must block an operation, make it return exit code 2 or the appropriate denial JSON. If a failed test returns 1 with ordinary text output only, that is a non-blocking error and the operation continues. PostToolUse runs afterward, so it is not a mechanism for undoing an operation already completed.

A hook can block only what its script evaluates at the configured event. Monitoring Edit alone does not cover writes made through a shell. Simple matching of dangerous strings is not comprehensive either. Combine hooks with permissions, a sandbox, and CI, and test both inputs that should pass and inputs that should be denied.

2. Separate responsibilities with subagents

Use subagent capabilities in the Claude Agent SDK or Cursor to create a dedicated rule-audit agent. Having an audit agent review code written by the main agent can reveal omissions from another perspective. However, both agents can still make the same mistake or overlook the same issue.

Give the reviewer the relevant rules, the diff, and the evidence you expect. A short prompt does not guarantee a high rate of rule recognition. Check each reported finding against the actual files or test results, and leave areas outside the reviewer’s remit marked as unverified.

3. Invoke repeatable procedures through skills

In Claude Code, you can put a repeatable procedure in .claude/skills/precommit/SKILL.md and invoke it as your own /precommit. This is an example you create yourself, not a built-in command. Files in the older .claude/commands/ directory still work, but the current documentation incorporates them into skills. Invoking a procedure is different from passing every check, so examine the results at the end.

See the official skills documentation for file locations and invocation. Put both the procedure and its verification conditions in the skill, and ask for evidence that the steps ran.

4. Detect violations with automated scripts

Use grep in CI or a pre-commit hook to detect prohibited patterns. Examples include:

• console.log left in production code
• Hard-coded API keys
• Missing copyright comments at the start of files

Scripts cannot check rules they do not implement or files outside their scope. Test valid examples, violations, and retrieval failures, and display how many items were checked or skipped. For example, if two of ten files cannot be read, the other eight passing does not mean “all files passed.”

5. Best practices by tool

See the Cursor rules documentation, GitHub Copilot custom instructions, and OpenAI’s AGENTS.md guide for tool-specific conditions. Copilot’s path-specific instructions use *.instructions.md; check support for each feature. Codex’s 32 KiB limit is a default combined byte limit, not a character or line count.

The common principle is “concise, specific, and clearly prioritized.” Filenames and locations vary by tool, but the writing principles remain the same.

6. Three rule-design anti-patterns

1. “Please follow best practices”

The request alone does not define “best practices.” Specify the methods your project uses and how to verify them. For “test appropriately,” name the required test commands and the workflow step that must stop if they fail.

2. Duplicating the same rule in several files

If the same commit conventions appear in CLAUDE.md, SPEC.md, and README.md, updates can leave the three copies inconsistent. Choose one source of truth and link to it from the other files.

3. Writing “absolutely must” everywhere

Giving every condition the same emphasis makes the priorities harder to communicate. Reserve “CRITICAL” for conditions with truly severe consequences, and use ordinary language for the rest. Remember that emphasis loses its value when overused.

Summary

When rules are not followed, investigate in this order: loading conditions → scope → conflicting instructions → execution results. Root CLAUDE.md is reinserted after compaction, so do not assume compression alone caused the problem. Concise wording, emphasis, and AI review provide support. Put reliably testable conditions in Hooks or CI, and define permitted operations through permission settings.

Evidence of completion comes from execution results and artifacts that cover the required scope, not from the reply “I read it.”

FAQ

Q1. What is the ideal length for CLAUDE.md?

The official guideline is fewer than 200 lines per file. This is neither a loading cutoff nor a guarantee of compliance. Keep rules needed every time, and separate the details with explicit conditions for reading them. Importing all those details back in does not reduce startup context.

Q2. Should I use Cursor’s .cursorrules or .cursor/rules/*.mdc?

For a new setup, use .cursor/rules/*.mdc. Keep one rule per file, with glob patterns to specify where it applies. The legacy .cursorrules is a single file that can become unwieldy.

Q3. Do longer rules make enforcement stricter?

Length alone does not make rules stricter. Adding necessary conditions or examples can help, but avoid introducing duplication or contradictions. Check what gets loaded and which conditions can actually be verified.

Q4. What if I use several AI tools, such as Claude Code and Cursor, on one project?

Keep one source of truth for shared rules, with separate entry points and settings for each tool. Codex and Cursor support AGENTS.md. In Claude Code, another option is to import @AGENTS.md from a CLAUDE.md that gets loaded. However, file discovery scope and exclusion settings differ. Placing a shared file in the project does not establish that every tool has received it.

Q5. If the AI says “I read it,” could it still be unread?

The reply alone neither proves that the file was unread nor establishes that it was read. Use the diagnostic steps in this article to check the loading display, and compare it with diffs, test results, and execution history.