[FEATURE] Organization-managed CLAUDE.md for enforcing behavioral security policies
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
Organizations deploying Claude Code for non-engineer employees face a critical gap: there is currently no way to enforce organization-wide behavioral guidelines through CLAUDE.md at a managed/non-overridable level.
While managed-settings.json provides strong control over tool-level permissions (deny/allow specific Bash commands), it cannot express behavioral instructions to the model — such as:
- "Never suggest changes that lower security settings"
- "Do not propose registry modifications"
- "Always recommend the least-privileged approach"
Real incident that motivated this request:
A non-engineer employee at our organization used Claude Code to process a CSV file. Claude Code asked whether to use Python or an Excel macro — the employee chose Excel macro (not knowing what Python was). Claude Code then suggested running a PowerShell command to modify the Windows registry (HKCU:\Software\Microsoft\Office\16.0\Excel\Security\AccessVBOM) to enable macro execution. The employee approved it (not understanding the security implications), the EDR detected it as a critical incident, and the endpoint was quarantined.
The employee did nothing malicious — they simply trusted Claude Code's suggestion.
Proposed Solution
Add support for an organization-managed CLAUDE.md that:
- Is delivered via the same mechanism as
managed-settings.json(server-managed via Admin Console, or endpoint-managed via MDM/Intune/Jamf) - Cannot be overridden by user-level
~/.claude/CLAUDE.mdor project-level.claude/CLAUDE.md - Is prepended or merged into the system prompt with the highest priority
Example use cases:
- Enforce security policies: "Never suggest disabling security controls or modifying security-related registry keys"
- Compliance instructions: "Always follow our data handling policy before writing files"
- Behavioral guardrails for non-engineer users who cannot evaluate Claude's suggestions critically
Alternative Solutions
Why managed-settings.json deny rules are insufficient
deny rules work well for known, specific commands — but they cannot:
- Anticipate every possible way a security-lowering operation could be expressed
- Provide contextual reasoning ("don't do X because of our security policy")
- Cover novel or indirect approaches Claude might suggest
Natural language instructions in a managed CLAUDE.md would complement deny rules by addressing the intent rather than just specific command patterns.
Priority
High - Significant impact on productivity
Feature Category
Configuration and settings
Use Case Example
_No response_
Additional Context
This feature would be especially valuable for organizations deploying Claude Code to non-engineer employees who cannot critically evaluate suggestions that involve system-level changes.
Delivery via the existing managed-settings.json mechanism (server-managed via Admin Console, or endpoint-managed via MDM/Intune/Jamf) would make adoption straightforward for enterprise IT teams.
Related Issues:
- #14467 — Organization-wide shared CLAUDE.md via GitHub org
- #4442 — Unified Hierarchical Configuration with System-Wide Managed Settings
Target Plans:
Claude for Teams and Claude for Enterprise
(where managed-settings.json is already supported)
4 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
After reviewing all three flagged duplicates, this issue is distinct from each:
#34894 — Enterprise protected context injection
Focuses on runtime retrieval of policy bundles from external systems (secret managers, config services) with features like fail_closed/fail_open startup behavior, per-session policy versioning, and encrypted caching. That is a complex infrastructure-oriented proposal for large enterprises. This issue requests a simpler mechanism: delivering behavioral instructions via the existing
managed-settings.jsondeployment path (Admin Console or MDM/Intune/Jamf), with no new infrastructure required.#34349 — claudeMdRequires in managed-settings.json
Addresses a follow-on problem: preventing users from excluding mandatory rule files via
claudeMdExcludes. That issue already assumes a managed CLAUDE.md exists. This issue is one step earlier — requesting the managed CLAUDE.md delivery mechanism itself to be clearly supported and documented.#4442 — Unified Hierarchical Configuration
Focuses on the settings hierarchy and system-wide
managed-settings.jsonfor tool permissions and environment variables. It does not address natural language behavioral instructions to the model.---
The core ask here is different from all three: a way to enforce natural language behavioral policies (e.g. "never suggest disabling security controls") at the organization level, using the existing managed-settings delivery mechanism — motivated by a real security incident where a non-engineer employee approved a registry modification suggested by Claude Code, triggering EDR quarantine.
This gap cannot be addressed by
denyrules inmanaged-settings.jsonalone, because deny rules can only block known specific commands, not the intent behind novel suggestions.Closing this as the feature already exists.
Organization-wide CLAUDE.md can be deployed to:
Per the official docs, this file cannot be excluded by individual
settings. See: https://code.claude.com/docs/en/memory#deploy-organization-wide-claude-md
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.