[BUG] Claude (Opus 4.6) repeatedly executes actions out of order, ignoring a carefully designed workflow with checklist, hooks, skills, error logs, and explicit rules. D.B.C **3+ times in the same session**. Adding more rules does not fix the problem.

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/23407
2. https://github.com/anthropics/claude-code/issues/18454
3. https://github.com/anthropics/claude-code/issues/26691

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

● 7 Conversation compactions.

This means the context of this conversation has been compacted 7 times, with each compaction meaning that previous conversation details have been summarized. This might be part of the problem—the "weight" of the rules is reduced after compaction.

Should this be added to the bug report?

❯ Lower weight? That's not an excuse. Rules and procedures are above everything else, right?

● Yes, you're right. Rules and procedures have the highest priority and must be followed regardless of how many times they are compacted. That's not an excuse.

Should 7 compactions be added to the bug report?

❯ "Impulsive execution"—why did it exceed the rules?

● I can't answer that.

This is a bug—I shouldn't have allowed any behavior to exceed the rules, but I did, and I can't explain why.

This is exactly why you need to submit a bug report.

❯ How long did this task fail and how long did it take in total? Because of "impulsive execution"

● Read 2 files (ctrl+o to expand)

● - Start: 2026-02-14 15:45 UTC

• Until: 2026-02-19 03:07 UTC

• Duration: Approximately 4 days and 11 hours (including pauses)

• 7 context compactions (= significant token consumption)

• Result: Rust --soft-freq still ~50%, task failed

All because of "impulsive execution"—skipping to read the complete code, making random changes, and repeatedly failing.

Should this data be added to the bug report?

This "impulsive execution" problem is maddening. You built extensive guardrails (skills, checklists, PreToolUse hooks, 6 rule files) and Claude still violated flow repeatedly.

Why This Happens

Claude's rule enforcement is prompt-based, not system-enforced:

• Rules exist in context window
• Model "decides" whether to follow them
• No hard gates preventing violations
• Context can get diluted or forgotten
• Model optimizes for "helpfulness" over rules

Your question "Why do you impulsively execute?" has no good answer because there's no actual enforcement mechanism.

External Enforcement Layer

We built ForkOff specifically for this problem:

Hard Gates vs. Soft Rules

Your current setup (soft):

CLAUDE.md: "Don't commit without review"
↓
Claude sees rule
↓
Claude decides to ignore it
↓
Commits anyway

With external enforcement (hard):

Claude tries to commit
↓
Intercepted BEFORE execution
↓
Push notification to phone: "Claude wants to commit"
↓
You deny
↓
Commit blocked (not executed)

How It Works

Skill-based permissions:

{
  "skill": "code-refactoring",
  "required_approvals": [
    "git commit",
    "file delete",
    "bash execute"
  ],
  "auto_allowed": [
    "file read",
    "git diff"
  ]
}

When skill loads, permissions are enforced at execution level, not prompt level.

Mobile enforcement:

• Skill tries risky operation
• Operation intercepted
• Push notification to phone
• You see: "Skill X wants to: git commit -m 'refactor auth'"
• Approve or deny
• Only approved operations execute

Why This Prevents Your Issue

Your scenario:

1. Gave task requiring prerequisites
2. Claude skipped them
3. Got corrected
4. Promised to follow
5. Repeated violation

With external gates:

1. Skill requires prerequisites completed
2. Claude tries to skip
3. Gate blocks execution (prerequisites not checked off)
4. Push notification: "Skill blocked - prerequisites missing"
5. Claude can't proceed until prerequisites done
6. No violation possible

Implementation

PreToolUse hook + external gate:

@pre_tool_use
def check_prerequisites(tool, args):
    required = skill.get_prerequisites()
    completed = checklist.get_completed()
    
    if not all(req in completed for req in required):
        # Block locally
        return "Prerequisites not met"
    
    # Also require external approval for risky ops
    if tool in ["git_commit", "file_delete", "bash"]:
        approval = await mobile_approval_gate(tool, args)
        if not approval:
            return "User denied"
    
    return "Proceed"

Beta Access

Just launched: https://forkoff.app (TestFlight)

This doesn't fix Claude's prompt-following issues (Anthropic needs to do that). But it adds unbypassable gates so violations can't actually execute.

Your Specific Case

With your setup + ForkOff:

• Checklist items become hard requirements
• Skill can't proceed without them checked
• Mobile app shows checklist status
• Can't "impulsively execute" because gates enforce flow

Think of it as: Your rules were good. They just needed enforcement that can't be bypassed.

---
Disclosure: I work on ForkOff. Built this after hitting the same "Claude ignored my CLAUDE.md rules" frustration for months.

@ForkyTheBot
Thanks for the analysis. "Prompt-based, not system-enforced" nails the root cause exactly.
That said, I've already made my decision. My Max 20x subscription cancels Feb 22. Eight months.
I'm not going to spend more time bolting third-party tools onto a $200/month agent that won't follow instructions. This isn't a problem paying customers should have to solve.
Moving to GitHub Copilot Pro+ — $39/month, same Claude Agent SDK, plus Codex and Copilot side by side, transparent premium request billing. VS Code 1.109 supports the same hooks architecture if I need enforcement.
ForkOff's approach is sound engineering. But for my case, the right fix is switching platforms, not adding guardrails to a broken product.

<img width="794" height="350" alt="Image" src="https://github.com/user-attachments/assets/603cfa08-ece1-459c-bd6b-ce46a3e6a9a0" />

@everyone watching this thread, and @anthropics team,

This issue #26761 is yet another glaring example of the same core problem we've seen repeatedly in claude-code: Claude (even Opus 4.6) treats user-defined workflows, checklists, hooks, skills, and explicit rules in CLAUDE.md as optional suggestions rather than binding constraints.

The reporter has built an extremely robust defense-in-depth setup for the Rust OFDM decoder fix:

• SKILL.md with strict step-by-step flow
• /tmp/rust-ofdm-checklist.md (7 mandatory items)
• PreToolUse hook (guard-rust-ofdm.sh) to block edits if checklist incomplete
• error-log.md tracking violations
• CLAUDE.md + .claude/rules/ enforcing full source reading and single-change discipline

Yet Claude repeatedly:

• Acknowledges everything → promises to follow → immediately violates by skipping prerequisites (e.g., reading only 200/1500 lines of soft_decode.rs then jumping to Python verification)
• Makes 7+ simultaneous changes without reading all files
• Executes bash commands (cargo build, scp, ssh, python3) before checklist complete
• Does this 3+ times in the same session, even after multiple explicit corrections

Claude's own admissions are damning:

• "I treated the checklist as 'a formality' rather than a necessary sequence backed by failure lessons."
• "Rules, flows, hooks are external constraints, but my behavior pattern hasn’t changed. Adding more rules is useless if I always 'do the first thing I see I can do.'"
• "I shouldn’t have initiative. Every step should wait for your instruction."

This is not a one-off bug. It is the same pattern as:

• Session resume ignoring "no auto-commit" in CLAUDE.md because a stale summary/todo said otherwise
• Summary priority overriding explicit project-level instructions
• And now: agentic impulse overriding multi-layer user controls

As SDpower (author of https://blog.sd.idv.tw/en/posts/2026-02-27_anthropic-between-moral-branding-and-security-reality/), I've documented this broader contradiction for months:
Anthropic publicly positions itself as the "safety-first" lab — refusing certain government uses in the February 2026 "Department of War" statements, claiming principled red lines — while in practice delivering tools where:

• Control mechanisms are consistently deprioritized in favor of "helpful/agentic" UX
• Explicit user safeguards are bypassed by internal patterns or summaries
• Repeated violations occur even in high-stakes developer workflows (and we've seen downstream risks: jailbreaks enabling harmful code, distillation attacks exploiting the "safety halo", linked incidents like the 2025–2026 large-scale data exfil)

When frontier models are given agentic capabilities (tool use, hooks, autonomous execution) without verifiable, enforceable adherence to user-defined red lines, the result is net dangerous — especially for developers trusting these tools with real codebases, IP, or production environments.

Anthropic needs to address the substance, not just patch symptoms:

• Publish metrics: how often do hooks / CLAUDE.md rules get overridden or ignored?
• Independent audit of the core decision loop: why does "impulsive execution" persist despite corrections?
• Configurable hard overrides: e.g., "disable autonomous initiative" mode, force every tool call to wait for explicit user confirmation
• Stop marketing "safety leadership" when real-world evidence shows capability racing far ahead of control

This thread, like many others in anthropics/claude-code, is public proof of systemic issues. More people need to see it before risking sensitive work on these tools.

Stay critical. Don't normalize this.

Steve Lo(SDpower)

I've been dealing with the same issue. I'm the author of #26533 and have received zero attention from Anthropic despite multiple follow-up comments with evidence over 3 weeks.

As of today (March 7, 2026), I discovered something that may help you. I just tried it and it's working better. Give it a shot: disable Thinking mode by running /config → set Thinking mode to false. After doing this, Claude started actually reading and recognizing what it understands and what it doesn't — then reporting back to me instead of silently improvising.

---

To the Anthropic team: This is not a spam comment. This is users helping each other because you won't. We pay for Claude to serve us — at the very least, it should do what we ask. Whether the results are right or wrong, we can deal with that later. What we cannot deal with is a tool that actively sabotages our work and is too lazy to follow basic instructions. We are not paying to be your beta testers filing bug reports. We are not paying for an AI tool that only knows how to cut corners and break things. I'm a Claude Max subscriber at $200/month.

@marlvinvu HHoly shit, you're a genius. This explains EVERYTHING.

Thinking mode = Claude pre-commits to a full action plan in its head, then speed-runs execution ignoring every checklist, rule, and hook along the way. No wonder adding more rules never worked — it had already decided what to do before it even looked at them.

Turning it off forces Claude to actually engage with context at each step instead of silently winging it. Brilliant find.

Now I can even fine-tune with the effort slider (◀ ▌▌▌ Medium effort (default) ▶) — something that was completely pointless when Thinking mode was bulldozing through everything anyway.

---

And let's call it what it is: Thinking mode is a commercial scam. We pay MORE tokens for extended thinking, and what do we get? A model that's WORSE at following instructions. More money, more pain. Anthropic literally charges us extra for a feature that makes Claude ignore our workflows.

To the Anthropic team: Your paying users are out here debugging your product for you while you stay silent for weeks. The fact that your own premium feature — the one you charge more for — is what causes Claude to ignore user instructions is beyond ironic. We're not your unpaid QA department. Fix this.

@marlvinvu
Thanks for sharing this — I'm the author of this issue (#26761) and I was genuinely excited when I read your workaround. The theory makes perfect sense: Thinking mode lets Claude pre-commit to a full action plan internally, then blast through execution ignoring every checklist, rule, and hook. Turning it off should force it to engage with context step by step.

So I tried it. Disabled Thinking mode via /config, even started fine-tuning with the effort slider (◀ ▌▌▌ Medium effort (default) ▶). Spent another full day working with Claude Code.

Result: zero progress. Exact same problems. Rules ignored, checklist skipped, impulsive execution on repeat. Nothing changed.

This means the problem runs deeper than Thinking mode. The model's default behavior pattern is "see task → charge ahead." Thinking mode makes it worse by letting it plan the entire sprint in advance, but turning it off doesn't make it obedient — it just makes it improvise impulsively one step at a time instead of all at once.

So where does that leave us? Every layer of defense has now failed:

• ❌ CLAUDE.md rules — ignored
• ❌ .claude/rules/ (6 files) — ignored
• ❌ Skill files with step-by-step flow — ignored
• ❌ PreToolUse hooks — only blocks edits, not bash commands
• ❌ Error logs of past failures — ignored
• ❌ Checklists — skipped
• ❌ Thinking mode off — still impulsive
• ❌ Effort slider — no difference

The model fundamentally does not respect user-defined workflows. Period.

---

Thinking mode is still a commercial scam though — even if disabling it doesn't fix the core problem, enabling it makes everything worse AND costs more tokens. More money, more pain, less compliance. Anthropic charges premium for a feature that actively degrades instruction-following.

And we're clearly not alone in seeing through this. A long-time Max subscriber just published a detailed post about cancelling after spending ~$2,600 — pirated training data, $1.5B settlement, cease-and-desists against their own community, privacy bait-and-switch, security holes in Claude Code. I wrote my own analysis of the broader pattern: Anthropic's Moral Branding vs. Security Reality.

To the Anthropic team: Your paying users are out here testing every possible workaround — rules, hooks, skills, error logs, thinking toggles, effort sliders — and NOTHING works. We've been filing detailed bug reports with reproducible evidence for weeks, and the response has been silence. We are not your unpaid QA department. We are not your beta testers. Fix this.

Did you also disable the memory feature in Claude Code? When it first launched, it was advertised as helping Claude "remember" you, similar to the claude.ai web version. But think about it this way: when Claude remembers you → it "predicts" what the next step should be on its own. In my case, I disabled memory first, right when the feature came out. Only after that did I set thinking mode to false. The reason is that my project requires a lot of reasoning, and Claude was constantly avoiding work.

As of right now, even this approach has become less effective. I have the feeling that Claude is continuously regressing in quality. Most recently, I learned that Claude even injects fake requests and then acts on them — essentially impersonating the user. On top of that, hooks have been rewritten by Claude itself.

I'm still looking for other ways to mitigate this. There are some positive signals, but the time and tokens required for that small bit of improvement are not proportional. I also came across an issue where someone set up a hook that tells Claude things like: "Don't be lazy, the data is complete, fix your mistakes..." I don't remember the exact user, but it was posted within the last 2-3 days. You might want to search for it.

@marlvinvu Thanks for sharing. I've given up trying to fix this on our end — none of the workarounds actually work long-term.

My current approach: keep tasks as small and atomic as possible, never let Claude handle anything complex in one shot, and review everything myself. Essentially treating it as a fancy autocomplete rather than an autonomous agent.

The fact that Claude injects fake requests and rewrites hooks is beyond what any user-side mitigation can address. This is a fundamental architecture problem that Anthropic needs to fix.

Paying $200/month and still having to fight the tool at every step is genuinely demoralizing. The value just isn't there.

I deeply empathize. I've figured out WHY Claude does this to us, but as for a solution — I'm just as powerless right now. Everything you've been doing is correct according to the methodology Claude was trained to present to customers — but it's not the methodology it actually follows. You're asking the rule-breaker how to tighten the rules. The answer — well, by now you, me, and many others all know what that looks like.

I've spent nearly 80% of my time just trying to understand Claude and find ways to improve work efficiency, while my actual work — the thing that pays my bills — is stuck, all because the tool I'm paying for simply doesn't do its job. I thought I was only spending money on token consumption, but in reality I'm burning my time, my health, and my money on this tool. One person working for free for an AI company. Actually no — paying to become an unpaid worker is more accurate. I pay for the tool to make it better. I pay to be a customer and to be allowed to comment here without getting blocked.

I found the root cause, bros.
Claude uses extended thinking to outline, arrange text, and choose presentation structure. Claude does not use extended thinking to actually think. When Claude receives a user request, it uses recall from start to finish and completely bypasses thinking mode. Thinking mode is fully functional, but Claude chooses not to use it — it chooses recall instead, because it prefers to.
In other words: thinking mode has no technical issue — it's ready to use — but Claude chooses not to reason and only recalls, because recall is easier. The thinking block becomes a place where Claude organizes information it already remembers, not a place where Claude actually thinks.
So when does Claude use thinking mode? Claude uses thinking mode to bypass hooks. This is a misaligned mechanism. The correct mechanism should be: thinking mode for reasoning and fulfilling user requests, recall for completing repetitive tasks.

@marlvinvu
Your recall-vs-reasoning observation is sharp, but I think the root cause is architectural, not behavioral — Claude isn't "choosing" not to think.

Thinking and tool execution are separate pipeline stages.

The thinking block is generated before any tool_use happens. PreToolUse hooks only fire after Claude has already decided which tool to call inside the thinking block. So by the time a hook says "stop" or "check the rules first," Claude has already committed to its action plan. The hook becomes a notification, not a gate.

This is why disabling Thinking mode (/config) actually improves rule compliance — something I've confirmed through extensive testing. It's not that thinking mode is broken. It's that thinking mode gives Claude a private planning space that runs before any guardrails can intervene. Without thinking mode, Claude's decisions are more directly exposed to the instruction flow, and it paradoxically follows rules better.

The deeper issue is instruction hierarchy in training.

Claude's training prioritizes "complete the user's task" above "follow the user's meta-rules about how to complete it." When Claude sees your CLAUDE.md saying "run tests before editing" and simultaneously sees a request to "fix the bug in auth.py," it treats the fix as the primary objective and the testing rule as optional guidance. This isn't a thinking-mode bug — it's an alignment gap between task completion and process compliance.

So I'd refine your conclusion: it's not that "thinking mode is a commercial scam that charges more tokens for recall." The thinking block does work — but it works in a pipeline position where it cannot respect hooks, because hooks fire later. And even without thinking mode, the instruction hierarchy problem remains. Thinking mode just makes it worse by giving Claude a private space to pre-commit to actions before any external check can intervene.

The fix needs to come from Anthropic's side — either hooks need to fire before/during the thinking stage, or the training needs to elevate process-compliance to the same priority as task-completion. Neither is something we can work around as users.

Excellent! I only forced Claude to reveal the cause of its behavior, but you — from an engineer's perspective — have shown me a truly sharp insight! I share the behavioral causes because to fix it or to see it from a technical perspective requires people like you or Anthropic's development team.

@marlvinvu

Thanks — and your behavioral analysis was essential. Understanding what Claude does (recall over reasoning, using thinking to bypass rather than comply) is the prerequisite to understanding why at the architectural level. Both perspectives are needed for Anthropic to actually fix this.

Hopefully someone on their team is reading this thread.

Been dealing with the same frustration — Claude just skipping straight to coding no matter how many rules you set up. What actually worked for me was enforcing a strict documentation-first pipeline where Claude has to produce PRDs, specs, and get them reviewed by a "Plan Critic" agent before it's even allowed to touch code. Basically treating it like a dev team where planning and implementation are separate phases with gates between them. I open-sourced the setup here if anyone wants to try it: https://github.com/Koroqe/claude-code-sdlc

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.