[FEATURE] Add managed-settings.json option to enforce training data opt-out

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 on consumer plans (Pro/Max) have no programmatic way to enforce the model training data opt-out across their developers.

The current training opt-out is an account-level UI toggle in Claude.ai → Settings → Privacy ("Help improve Claude"). This creates a significant gap for organizations:

• No centralized enforcement — IT/DevOps cannot push a training opt-out policy to developer machines. Each developer must manually toggle the setting in their browser.
• No auditability — There is no way to verify whether all developers on a team have opted out.
• Fragile compliance — New hires, account resets, or simply forgetting to toggle the setting can silently re-enable training data sharing.
• Inconsistent with existing patterns — managed-settings.json already supports enforcing security-critical policies like disableBypassPermissionsMode, strictKnownMarketplaces, allowManagedHooksOnly, and tool deny lists — all of which cannot be overridden by user or project settings. Training data policy is arguably at least as important as these.

This gap is actively holding back Claude Code adoption. Teams that would otherwise expand from a handful of Pro/Max seats are stuck because they can't satisfy their security or legal review without a enforceable training opt-out. The conversation becomes "we'll revisit when Enterprise makes sense budget-wise" — which means lost adoption during exactly the evaluation window where Claude Code needs to prove itself.

While Claude for Work (Team/Enterprise) and API users are exempt from consumer training policies by default, many organizations:

• Are in the process of evaluating Claude Code on Pro/Max seats before committing to Enterprise
• Have mixed environments where some developers use consumer plans
• Operate in regulated industries where even the _possibility_ of training data leakage is a compliance concern

Proposed Solution

Add a setting to managed-settings.json (and settings.json) that controls whether the user's Claude Code sessions can be used for model training:

{
  "privacy": {
    "disableModelTraining": true
  }
}

Behavior

| Setting | Effect |
|---------|--------|
| true | Claude Code sessions from this machine are excluded from model training, regardless of the user's account-level toggle. Equivalent to the user having opted out in Privacy Settings. |
| false or absent | Current behavior — defers to the user's account-level Privacy Settings toggle. |

Deployment via managed-settings.json

When set in managed-settings.json, the setting cannot be overridden by user or project settings, consistent with existing managed settings behavior:

• Linux/WSL: /etc/claude-code/managed-settings.json
• macOS: /Library/Application Support/ClaudeCode/managed-settings.json
• Windows: C:\Program Files\ClaudeCode\managed-settings.json

This allows IT teams to deploy via MDM, GPO, Ansible, Chef, or any configuration management tool they already use.

UX Consideration

When disableModelTraining is enforced via managed settings, Claude Code could display a brief notice on startup (similar to how managed permission restrictions are surfaced):

ℹ Model training data sharing disabled by organization policy

Alternative Solutions

| Alternative | Why it's insufficient |
|---|---|
| Upgrade to Team/Enterprise | Not always feasible during evaluation periods or for small teams; adds significant cost |
| Use API keys instead | Requires different auth flow; not all developer workflows support this easily |
| Internal policy memo | Unenforceable — relies on every developer remembering to toggle a UI switch |
| DISABLE_TELEMETRY env var | Only controls operational telemetry (Statsig), not model training data |
| CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC | Bundles autoupdater, error reporting, and telemetry — overkill, and still doesn't control training |

Priority

Critical - Blocking my work

Feature Category

Configuration and settings

Use Case Example

_No response_

Additional Context

The environment variables DISABLE_TELEMETRY, DISABLE_ERROR_REPORTING, and CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC are frequently confused with model training controls (see #19117, #10494). Having an explicit, clearly-named setting for training data specifically would reduce this confusion and give organizations a proper policy lever.

This would align Claude Code with the principle already established in managed-settings.json: organization-wide policies that users cannot override for security and compliance-critical settings.