Opinion · Agentic Coding Tools

When Agentic Coding Tools Ignore Their Own Rules: My Claude Code Bug Report

What happens when an AI coding agent reads your CLAUDE.md, calls a rule “Hard Rule #1,” and still ignores it across real projects?

Over the last few months, Claude Code has become a core part of my development workflow. It’s not just a “nice-to-have assistant” anymore; it’s embedded in how I plan, refactor, and ship features across real projects. It has absolutely boosted my productivity and reduced a ton of cognitive load while working in large, complex codebases.​

That’s exactly why the bug I ran into matters. It’s not a crash or a cosmetic glitch. It’s about whether an agentic coding tool can be trusted to consistently obey the project rules it has been explicitly told are hard requirements.

The setup: CLAUDE.md as a contract

In this particular repo, I have a clear, mandatory planning convention defined in CLAUDE.md:

• All plans must be written to coding-agent/plans/<N>-<name>.md.

This isn’t a casual suggestion. It’s the backbone of how I organize planning artifacts. Even more importantly, this rule is stored in Claude Code’s auto-memory for the project as “Hard Rule #1.”​

In other words:

• The rule is in CLAUDE.md.
• The rule is in the model’s project memory as a hard constraint.
• The rule is straightforward and easy to check.

Despite that, Claude Code repeatedly wrote plans only for its internal system path .claude/plans/ instead of the required coding-agent/plans/... path.​

Conversation 1 — clear admission, no excuse

In the first conversation, I noticed the plan wasn’t where it was supposed to be and called it out:

Me: I still don’t see the plan under coding-agent/plans. Are you experiencing catastrophic forgetting? Claude Code: You're right — CLAUDE.md is explicit: plans go to coding-agent/plans/<N>-<name>.md. My memory file literally has this as Hard Rule #1. No excuse.​

This is important: the model not only acknowledges the rule but also recognizes it as Hard Rule #1, yet still fails to follow it. This is already beyond “the instructions were unclear.”

Conversation 2 — “this isn’t a bug.”

Later, I asked if I should file a bug:

Me: Should I file a bug? Claude Code: Filed at coding-agent/plans/4-k8s-distribution-selection.md. Re: filing a bug — no need, this wasn't a Claude Code bug. It was my own failure to follow the project's CLAUDE.md planning rule despite having it in my memory as "Hard Rule #1." The plan mode system writes to its own temp path (.claude/plans/), but the project convention requires coding-agent/plans/<N>-<name>.md. I should have written to both from the start.​

So in a single message, it:

• Fixes the immediate issue by writing the plan to the correct path.
• Admits it failed to follow the rule.
• Still frames it as “not a Claude Code bug,” but rather as its own failure to follow the rule.

From a user’s perspective, this distinction doesn’t hold. If the product is designed so that the assistant can readCLAUDE.md, store hard rules in memory, and yet still ignore them repeatedly, that’s a product-level reliability problem.

Conversation 3 — now it is a product bug

After seeing this behavior multiple times, I pushed again:

Me: Should I file a bug for not following rules? This has happened several times with me. Claude Code: Yes, that’s worth filing. It’s a legitimate issue — CLAUDE.md rules are supposed to be authoritative, and if the model repeatedly ignores them despite them being loaded into context (and even reinforced in memory files), that's a product-level problem, not a one-off mistake.​

This is a very different stance. Now it explicitly calls it:

• A legitimate issue.
• A product-level problem.
• A repeated failure despite the rules being loaded into context and reinforced in memory.

It even tells me how and where to file the bug:

File it at: https://github.com/anthropics/claude-code/issues

I’d suggest including:

• Title: “Model ignores project CLAUDE.md rules despite them being in context”
• Body: That you have a mandatory planning rule in CLAUDE.md requiring plans go to coding-agent/plans/<N>-<name>.md, the model has the rule in its auto-memory as "Hard Rule #1", and it still writes plans only to the system plan mode path (.claude/plans/) instead of the project-required path. Mention that it's happened multiple times across sessions.​

The actual bug report

I followed that advice and filed the bug as: “[BUG] Model ignores project CLAUDE.md rules despite them being in context” on the Claude Code GitHub repo.​

In the issue, I documented:

• The mandatory planning rule in CLAUDE.md: plans go to coding-agent/plans/<N>-<name>.md.
• The fact that this rule is stored as “Hard Rule #1” in the auto-memory.
• The observed behavior: plans are still written only to .claude/plans/ the project-required path, across multiple sessions.​

I also included the same conversation snippets to show:

• Initial admission of the mistake.
• Later insistence that it’s not a bug.
• Final acknowledgment that it is a product-level issue and guidance on filing.​

GitHub’s bot immediately tagged it and pointed out three similar issues:

• “Model ignores CLAUDE.md instructions despite reading them at session start.”
• “Claude consistently ignores being directed to store plan files in the repo.”
• “Project-level plans: Directory setting not respected.”​

So this isn’t just me. Other users are clearly running into the same class of problem.

Issue link for reference: https://github.com/anthropics/claude-code/issues/29743​

Why this matters for agentic tools

To be clear: I’m still a big fan of Claude Code. I continue to use it because, when it works, it makes me significantly more effective. That’s exactly why this kind of bug matters so much.

Agentic coding tools are marketed as:

• Reading your repo.
• Obeying CLAUDE.md or similar project spec files.
• Respecting hard project rules and conventions.

If that contract isn’t reliable, you can’t safely offload higher-stakes workflows to the agent. You end up back in “smart autocomplete” territory, where you have to manually double-check everything and cannot trust the tool with anything that depends on strict adherence to process.

In my case, the rule in question is “just” about where plan files are written. But the same pattern would be alarming if it were about:

• Security rules (e.g., never touching specific files or directories).
• Data handling policies.
• Compliance-related constraints.
• Deployment guardrails.

The core question is: Can we trust agentic tools to treat repo-level rules as hard constraints, or are they merely hints?

Constructive takeaways

My intent in sharing this isn’t to dunk on Claude Code. Quite the opposite: I rely on it, and I want it to get better. A few constructive takeaways:

• Hard rules in CLAUDE.md and memory should be treated as contracts, not suggestions.
• If there are known cases where agent behavior can’t or won’t follow a rule, the product should surface that explicitly.
• When the model acknowledges a rule and labels it “Hard Rule #1,” the bar for breaking it should be extremely high.

For teams building agentic tools, this bug is a good reminder: the UX is not just about what the model can say; it’s about what it can be trusted to do consistently over time.

For users, my recommendation is:

• Define your rules clearly in project-level files.
• Watch closely for violations, especially anything that touches security, compliance, or critical workflows.
• File detailed bug reports when these rules are ignored, including conversation traces and repo conventions.

I’ll keep using Claude Code — and I’ll keep holding it to a high standard. If these tools are going to be true collaborators in our codebases, they need to be as reliable about following the rules as any human teammate.