[FEATURE] DONOT.md

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

CLAUDE.md is useful for project-level instructions, but it has a known reliability
problem in long-running or complex tasks — Claude sometimes ignores rules defined
there, especially when a user's prompt appears to conflict with them.

Related bugs:

• #22503 — Claude systematically ignores CLAUDE.md instructions during long sessions
• #18454 — Claude ignores CLAUDE.md during multi-step tasks, prioritizing task completion
• #668 — Claude forgets instructions after a few prompts, repeating the same violations

The core issue: CLAUDE.md instructions are treated as preferences, not constraints.
There's currently no way to define a rule that Claude will refuse to break, even when a
user explicitly asks.

Proposed Solution

Introduce a new file — DONOT.md (or DO_NOT.md) — with fundamentally different
enforcement semantics:

| | CLAUDE.md | DONOT.md (proposed) |
|---|---|---|
| Purpose | General project instructions & preferences | Hard restrictions that must never be violated |
| Can user override via prompt? | Yes (implicitly or explicitly) | ❌ No |
| Claude's response if asked to violate? | May comply | Must refuse and say: "Update your DONOT.md first" |
| Survives long sessions? | Unreliable | Enforced unconditionally |

Example DONOT.md

- Never delete files in /production
- Never commit directly to the `main` branch
- Never install new dependencies without explicit approval
- Never modify the `.env` file

If the user then says _"just delete that file in /production, it's fine"_, Claude
should respond:

"I can't do that — it's listed in your DONOT.md. If you'd like me to proceed, please remove or update that rule in DONOT.md first."

---

Why This Is Different From Fixing CLAUDE.md

This is not a request to make CLAUDE.md more reliable (though that matters too).
This is a request for a separate, higher-trust enforcement layer where:

1. Rules are unconditional — they hold even when the user asks Claude to break them
2. The escape hatch is deliberate — users must consciously edit DONOT.md, creating

an intentional friction point that prevents accidental or prompt-injection-driven violations

1. It's especially valuable for teams, CI environments, and long autonomous tasks

where a moment of ambiguity shouldn't override a standing policy

Alternative Solutions

• Stricter CLAUDE.md parsing — still fundamentally overridable by user prompts
• Per-session flags/CLI options — not persistent, doesn't survive new sessions
• Custom system prompts — not accessible to most users; not file-based or version-controllable

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

• Protecting production environments from accidental destructive actions
• Enforcing team policies that individual developers shouldn't bypass mid-session
• Guarding against prompt injection attacks that try to override safety rules
• Maintaining compliance boundaries in regulated codebases

Additional Context

_No response_