[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:

1. Is delivered via the same mechanism as managed-settings.json (server-managed via Admin Console, or endpoint-managed via MDM/Intune/Jamf)
2. Cannot be overridden by user-level ~/.claude/CLAUDE.md or project-level .claude/CLAUDE.md
3. 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)