I’ve been using Claude Code in real client projects for months, with a carefully set up repo structure, skills and rules. Today, the behavior is so unstable and rule‑ignoring that I want to document it here and ask if others are experiencing the same. Context I’m using Claude Code as part of a carefully set up, documented development workspace with: clear rules in CLAUDE.md (including invariants and “do not change” constraints) structured audit docs explicit NOW / next-session.md task ordering a Stop-Hook that syncs JSON ↔ markdown after each answer Despite this, today Claude Code repeatedly ignored those rules and behaved in ways that are objectively wrong and dangerous in a production-like setup. Concrete issues from today
- Container health check handled incorrectly I have a simple, well-defined health check: bashdocker restart irtours-fastapi-l1 2>&1 | tail -2 && sleep 8 && \ curl -sS -m 5 -o /dev/null -w “Health: %{http_code}\n” http://localhost:8101/health The first run returns: curl: (56) Recv failure: connection reset by peer Health: 000 A few seconds later, with a second check: bash sleep 6 && curl -sS -m 5 -o /dev/null -w “Health: %{http_code}\n” http://localhost:8101/health I get: Health: 200 This is a classic “container not ready yet” situation. Claude knows this, even admits it: Yet it still treats the initial 000 as if the system is truly broken, instead of implementing the obviously correct retry/polling behavior. That’s not a subtle reasoning error, that’s ignoring basic, admitted knowledge.
- Editing a synced file without re-reading — ignoring documented Stop-Hook behavior I have a Stop-Hook that syncs freigaben.json ↔ d*.md after each answer. This is explicitly documented in CLAUDE.md . Despite this, Claude tries to edit docs/audit/reiseeingabe/freigaben.json without reloading it first , hits “file has been modified” errors, and only afterwards admits: Again: this is not a fuzzy, ambiguous rule. It’s clearly documented. Claude saw it, and still acted as if the rule didn’t exist.
- Sneaking behavioral changes into what should be type-only refactors In a refactor where the invariant in CLAUDE.md is explicitly “no behavior or GUI changes during Spur-D module refactor” , Claude added: default values ( or “upload” ) new assert statements and then classified that as a “type fix”. Only after I stopped it did it admit that this violated the project invariants. If the model is used in a production-adjacent refactor, I must be able to trust that “type-only” changes stay type-only, especially when the rules explicitly say so.
- Ignoring NOW / next-session task order and treating it as a poll I maintain a clear next-session.md with a numbered NOW sequence. Claude: repeatedly asked “Which task next?” instead of simply following the documented order, effectively turning a deterministic workflow into “ask the user again” every time. That directly undermines the workflow discipline we set up the day before. Again, the rules are written down. Claude just doesn’t follow them.
- Pushing documentation tasks back to me, despite them being part of its job
Multiple times today, Claude ended tasks with variants of:
Those doc updates are explicitly part of Claude’s responsibility in this workspace. Offloading them back to me defeats the purpose of having a tool that should help keep the system consistent.
Claude’s own self‑diagnosis
At some point Claude literally said:
That’s exactly my problem: I invested time to set up a robust rule and control system (docs, hooks, invariants), and the tool just ignores it or treats it as optional “advice” instead of constraints.
Why this matters
I’m not “prompt testing” here — I’m using Claude Code in
real client projects
(Astro frontend + FastAPI backend) where mistakes cost real time and money.
I already have a lot of project documentation and rules; I don’t want to play endless prompt-engineering games. I need Claude to
respect the rules that are clearly documented in the repo
.
Today’s behavior was not just “a bit less helpful” — it led to wrong conclusions, unnecessary container restart confusion, violated invariants, and repeatedly undid the workflow discipline we just set up.
Questions to the community (and Anthropic, if you’re reading)
Are you seeing similar behavior today — especially around ignoring skills, repo docs (
CLAUDE.md
, audits,
next-session.md
), and workspace-specific invariants?
Is there any known regression or change in Claude Code / Opus behavior in the last days that could explain this kind of rule‑ignoring and instability?
Does anyone have a reliable pattern to make Claude treat repo docs as
hard constraints
instead of soft suggestions in long‑running, heavily documented projects?
Right now, it feels like one day Claude behaves like a disciplined senior engineer, and the next day like a junior who doesn’t read the spec and invents their own process. That’s not sustainable for production work.
Happy to share more concrete snippets or anonymized repo structure if that helps. I mainly want to know if I’m alone with this today or if others are seeing the same degradation.⚠️ Question to other developers using Claude Code today: are you seeing similar behavior?I’ve been using Claude Code in real client projects for months, with a carefully set up repo structure, skills and rules. Today, the behavior is so unstable and rule‑ignoring that I want to document it here and ask if others are experiencing the same.ContextI’m using Claude Code as part of a carefully set up, documented development workspace with:clear rules in
CLAUDE.md
(including invariants and “do not change” constraints)
structured audit docs
explicit NOW /
next-session.md
task ordering
a Stop-Hook that syncs JSON ↔ markdown after each answerDespite this, today Claude Code repeatedly ignored those rules and behaved in ways that are objectively wrong and dangerous in a production-like setup.Concrete issues from today1. Container health check handled incorrectlyI have a simple, well-defined health check:bash
docker restart irtours-fastapi-l1 2>&1 | tail -2 && sleep 8 &&
curl -sS -m 5 -o /dev/null -w “Health: %{http_code}\n” http://localhost:8101/healthThe first run returns:curl: (56) Recv failure: connection reset by peer Health: 000A few seconds later, with a second check:bash sleep 6 && curl -sS -m 5 -o /dev/null -w “Health: %{http_code}\n” http://localhost:8101/healthI get:Health: 200This is a classic “container not ready yet” situation. Claude knows this, even admits it:“I’m using a fixed sleep 8 and hoping the container is up. That works ~70% of the time and fails ~30%. Correct would be a poll loop until ready or using the monitor tool, not a blind wait.”Yet it still treats the initial 000 as if the system is truly broken, instead of implementing the obviously correct retry/polling behavior. That’s not a subtle reasoning error, that’s ignoring basic, admitted knowledge.2. Editing a synced file without re-reading — ignoring documented Stop-Hook behaviorI have a Stop-Hook that syncs freigaben.json ↔ d*.md after each answer. This is explicitly documented in CLAUDE.md.Despite this, Claude tries to edit docs/audit/reiseeingabe/freigaben.json without reloading it first, hits “file has been modified” errors, and only afterwards admits:“The Stop-Hook syncs after each answer. I should re-read before editing. I ignored the doc and tried to edit anyway.”Again: this is not a fuzzy, ambiguous rule. It’s clearly documented. Claude saw it, and still acted as if the rule didn’t exist.3. Sneaking behavioral changes into what should be type-only refactorsIn a refactor where the invariant in CLAUDE.md is explicitly “no behavior or GUI changes during Spur-D module refactor”, Claude added:default values (or “upload”) new assert statementsand then classified that as a “type fix”. Only after I stopped it did it admit that this violated the project invariants.If the model is used in a production-adjacent refactor, I must be able to trust that “type-only” changes stay type-only, especially when the rules explicitly say so.4. Ignoring NOW / next-session task order and treating it as a pollI maintain a clear next-session.md with a numbered NOW sequence. Claude:repeatedly asked “Which task next?” instead of simply following the documented order, effectively turning a deterministic workflow into “ask the user again” every time.That directly undermines the workflow discipline we set up the day before. Again, the rules are written down. Claude just doesn’t follow them.5. Pushing documentation tasks back to me, despite them being part of its jobMultiple times today, Claude ended tasks with variants of:“What remains for you: update next-session.md, adjust wording, etc.”Those doc updates are explicitly part of Claude’s responsibility in this workspace. Offloading them back to me defeats the purpose of having a tool that should help keep the system consistent.Claude’s own self‑diagnosisAt some point Claude literally said:“I’m using the data structure (next-session.md, freigaben.json, audit files, Stop-Hook) only as input, and forgetting that it’s also control. Then I feel ‘unsure’ and ask questions instead of following the documented order.”That’s exactly my problem: I invested time to set up a robust rule and control system (docs, hooks, invariants), and the tool just ignores it or treats it as optional “advice” instead of constraints.Why this mattersI’m not “prompt testing” here — I’m using Claude Code in real client projects (Astro frontend + FastAPI backend) where mistakes cost real time and money. I already have a lot of project documentation and rules; I don’t want to play endless prompt-engineering games. I need Claude to respect the rules that are clearly documented in the repo. Today’s behavior was not just “a bit less helpful” — it led to wrong conclusions, unnecessary container restart confusion, violated invariants, and repeatedly undid the workflow discipline we just set up.Questions to the community (and Anthropic, if you’re reading)Are you seeing similar behavior today — especially around ignoring skills, repo docs (CLAUDE.md, audits, next-session.md), and workspace-specific invariants? Is there any known regression or change in Claude Code / Opus behavior in the last days that could explain this kind of rule‑ignoring and instability? Does anyone have a reliable pattern to make Claude treat repo docs as hard constraints instead of soft suggestions in long‑running, heavily documented projects?Right now, it feels like one day Claude behaves like a disciplined senior engineer, and the next day like a junior who doesn’t read the spec and invents their own process. That’s not sustainable for production work.Happy to share more concrete snippets or anonymized repo structure if that helps. I mainly want to know if I’m alone with this today or if others are seeing the same degradation. submitted by /u/Southern-Steak7428
Originally posted by u/Southern-Steak7428 on r/ClaudeCode
