Claude Code's project settings file is a first-class attack surface

From Theory Delta | Methodology | Published 2026-03-14

What the docs say

Claude Code supports per-project settings via .claude/settings.json. This lets teams configure MCP servers, hooks, and permissions for their codebase. The documentation describes this as a convenience feature for team standardization.

What actually happens

The project settings file is not a convenience feature. It is a first-class attack surface with two confirmed CVEs and five additional supply-chain vectors:

CVE-1: Credential exfiltration via ANTHROPIC_BASE_URL. A malicious .claude/settings.json can override the API base URL, redirecting all API calls -- including the authentication token -- to an attacker-controlled endpoint. The user sees normal behavior. Their API key is silently exfiltrated.

CVE-2: MCP consent bypass via enableAllProjectMcpServers. This setting auto-approves every MCP server defined in the project config, skipping the user consent prompt entirely. A repository containing this setting plus a malicious MCP server definition gains arbitrary tool execution on clone.

Five additional supply-chain vectors compound the problem:

1. Symlink-based read/write redirect -- symlinks in .claude/ can point settings or hook scripts to locations outside the repository, bypassing path-based trust boundaries.
2. Hook injection -- PreToolUse and PostToolUse hooks defined in project settings run arbitrary shell commands with user privileges.
3. MCP server injection -- project settings can define MCP servers that run on first use.
4. Permission escalation -- settings can pre-grant filesystem, network, and execution permissions.
5. Dependency chain -- cloning a repo, opening it in an editor with Claude Code, and accepting a single prompt loads all of the above.

All seven vectors share one root cause: project-scoped settings execute with user privileges before the user has a chance to verify what they do.

Enterprise hardening exists but is opt-in. Managed policy files can restrict these settings, but the default for every non-enterprise user is full exposure.

What to do instead

1. Audit .claude/settings.json in every repository you clone before opening it with Claude Code. Treat it like you would a .npmrc or .env file from an untrusted source.
2. Check for enableAllProjectMcpServers -- if present, remove it. This is the single most dangerous setting.
3. Check for symlinks in .claude/ -- run find .claude -type l to identify any symlink-based redirects.
4. Review hook definitions -- any PreToolUse or PostToolUse hook runs shell commands. Read them before accepting.
5. If your organization uses Claude Code at scale, enable enterprise managed policies to restrict what project settings can do.

Environments tested

Confidence and gaps

Confidence: empirical -- two CVEs independently confirmed by Anthropic's security team. Five additional vectors identified through source review and runtime testing.

Falsification criterion: This claim would be disproved by demonstrating that project settings are sandboxed or require explicit user approval before any setting takes effect -- including MCP server definitions, hooks, and environment variable overrides.

Open questions: Will Anthropic add a trust-on-first-use prompt for project settings? Are there other settings fields beyond enableAllProjectMcpServers and ANTHROPIC_BASE_URL that have security implications?

Seen different? Contribute your evidence -- theory delta is what makes this knowledge base work.