[FEATURE] Repository-level AI Policy File (AI-POLICY.txt) for Client Compliance

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

Many development agencies and consultancies work simultaneously on multiple client projects, each with different contractual requirements regarding AI-assisted code generation. Currently, there is no repository-level mechanism to signal these restrictions before Claude Code begins operating.

Real-World Context

Our organization manages 15+ active client projects with varying AI usage policies:

• Client A (Fintech): NDA explicitly prohibits AI code generation due to IP concerns
• Client B (Startup): Actively encourages AI tools for development velocity
• Client C (Healthcare): Requires case-by-case legal approval for AI assistance

A single developer switches between these repositories daily. Without repository-level policy signaling, it's too easy to accidentally violate client contractual agreements.

Critical Gap

This problem cannot be solved by existing mechanisms:

| Mechanism | Why It Doesn't Solve This |
|-----------|---------------------------|
| CLAUDE.md | Provides instructions to the LLM, but execution has already started. No "stop and think" moment for the developer. |
| .aiignore | Controls which files Claude can read, not whether Claude should be used at all. |
| System-wide managed settings (#4442) | Too broad - affects all repositories on a machine, not individual client projects. |
| Project settings (.claude/settings.json) | Relies on LLM behavior, not pre-execution blocking. Also more technical/hidden than a clear policy declaration. |

What we need: A pre-execution policy check that happens before any LLM interaction - similar to how web crawlers respect robots.txt before accessing a site.

Proposed Solution

Introduce an AI-POLICY.txt file in the repository root that Claude Code checks during CLI initialization, before any API calls or context building.

File Format

# AI-POLICY.txt
Coding-agent: *
Disallow: /

Reason: NDA with client prohibits AI code generation
Contact: legal@company.com

Behavior Flow

1. Developer runs claude in a repository
2. Before any LLM initialization, Claude Code checks for AI-POLICY.txt in repo root
3. If Disallow: / detected, show blocking warning:

```
⚠️ AI Policy Restriction Detected

This repository has an AI-POLICY.txt file that prohibits coding agent usage.

Reason: NDA with client prohibits AI code generation
Contact: legal@company.com

Do you want to proceed anyway? (y/N) [Default: No]
```

1. Log the decision for audit trail purposes
2. If developer proceeds, Claude Code continues normally (with decision logged)

Alternative Solutions

_No response_

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

We run a dev agency working with 15+ clients simultaneously, and here's a problem we keep running into: some clients contractually prohibit AI code generation (NDAs, regulatory compliance, IP concerns), while others actively encourage it.

Right now, there's no way to signal these restrictions at the repository level before Cursor starts working. This means developers can accidentally violate client agreements just by opening Cursor in the wrong repo.

The Problem:

• Client A (fintech): NDA says "no AI code generation whatsoever"
• Client B (startup): "Use AI tools, go fast!"
• Client C (healthcare): "Case-by-case approval required"

A single dev switches between these repos regularly, and without repository-level signaling, it's way too easy to slip up and accidentally use the coding agent for a repository where it's not allowed.

Additional Context

Why "AI-POLICY.txt"?

• Clear, self-documenting name
• Follows established convention (similar to SECURITY.txt, robots.txt)
• Easy for non-developers to find and understand
• .txt extension ensures it's human-readable without special tools

Why not a JSON/YAML config?

• Accessibility: Legal teams and clients should be able to read/verify the policy
• Simplicity: No parsing complexity for such a simple use case
• Precedent: robots.txt has worked well for 30 years with simple syntax

Comparison with Related Issues

• #4442 (System-wide managed settings): Complementary, not competing - that's for machine-level policies, this is for repository-level
• #79, #1104 (.aiignore/.claudeignore): Those control file access; this controls usage authorization
• #617 (Remove git attribution): Similar theme of enterprise control, but different mechanism