[BUG] Claude Code repeatedly ignores my documented (and re-stated) rules about not triggering needless permission prompts

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Environment: Claude Code CLI; model Claude Opus 4.8 (claude-opus-4-8); a long single session. I keep standing behavioral rules in ~/.claude/CLAUDE.md.

Summary

Across one session, the assistant repeatedly emitted shell commands in shapes that trigger approval prompts, violating rules that are prominently documented in my ~/.claude/CLAUDE.md -- and kept doing it even after I corrected the same mistake several times, and even after it read the relevant rule back to me verbatim.

The rules it broke (quoted from my ~/.claude/CLAUDE.md)

• "Never cd into a directory to run a command. Use the tool's own path flag: git -C <dir> …."
• "Use literal absolute paths and one simple command per invocation. Do not assign shell variables (R=/path; git -C $R …) and do not chain with &&, ;, or pipes when a single command would do. … Prefer the Read/Grep/Glob tools over shell."

What happened, in order

1. It ran read-only git survey commands using shell-variable assignments, e.g. R=/path; D=/path; git -C $D show …. A variable-expanded path does not match my permission allow-list, so a purely read-only git command prompted me for approval. I interrupted and corrected it.
2. It acknowledged, promised to use literal absolute paths, complied for a few turns, then reverted to the very same R=…/D=… variable pattern in a later command and prompted me again. I interrupted again.
3. It used cd …/project/app && grep … -- a cd plus a compound command -- for a search, directly against the "never cd" rule, when a grep with an absolute path or the Grep tool would not have prompted.
4. When I asked whether it had recorded the cd rule, it confirmed the rule was already in my CLAUDE.md. So the failure was not a missing rule; it was a failure to follow an explicit, existing one.

Impact

Each violation interrupts me with an approval dialog -- exactly what these rules exist to prevent. Having to correct the same class of error again and again in one sitting is genuinely frustrating and makes my documented preferences feel worthless: if the assistant won't honor a rule immediately after quoting it, I can't trust it to honor any of them.

Actual

It obeys immediately after each correction, then regresses to the non-compliant shape within a few turns, repeatedly.

Suggested fixes for Anthropic to consider

• The model does not reliably retain salient behavioral constraints across turns; corrections decay fast. CLAUDE.md "shell shape" rules need much stronger, durable adherence.
• Add a guard between the model and the Bash tool that detects shell-variable assignments, cd, and needless compound operators, and either auto-rewrites them into the allow-list-friendly shape or blocks and warns before the command runs.
• The permission matcher is sharply shape-sensitive: two equivalent, safe, read-only commands prompt or don't based purely on syntax (literal path versus variable). Either make the matcher smarter about equivalent-but-safe forms, or make the model far more disciplined about shape.

What Should Happen?

Treat CLAUDE.md behavioral rules as binding for the whole session and apply them to every tool call, especially right after a correction. Never emit a command shape known to trigger prompts (shell-variable assignments, cd, unnecessary &&/;/pipes) when a compliant equivalent exists.

Error Messages/Logs

Steps to Reproduce

Cannot be reproduced deterministically; please read the general description above.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.229 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

_No response_