Protecting secret files

Environment files such as .env often hold API keys, database URLs, and tokens. Claude Code does not recognize .claudeignore. A file with that name has no product behavior unless your own hooks or scripts consume it.

Document the policy separately

You may keep a human-readable policy file, but label it clearly as documentation. Do not teach gitignore negation as a Claude Code control:

# SENSITIVE_PATHS.md — team policy, not Claude Code configuration
.env
*.pem
*.key
secrets/
config/credentials.json

Commit .env.example with placeholders, never real values. Because deny rules do not support allowlist exceptions, avoid a broad .env.* deny when .env.example must remain readable.

Enforcement: permissions.deny

Use explicit Read(...) rules in .claude/settings.json to block built-in file tools and recognized shell operations:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)",
      "Read(./**/*.pem)",
      "Read(./**/*.key)"
    ]
  }
}

See Permissions for path syntax.

Harden subprocess access

For stronger enforcement, configure sandbox.filesystem.denyRead and, where appropriate, the sandbox credentials controls. These constrain subprocesses after a command is approved; see Sandbox mode and Sandboxing.

Supporting habits

• Keep real secrets only in .env or a secret manager; commit .env.example with empty or placeholder values.
• Rotate anything that ever appeared in chat, logs, or a pasted diff.
• For organization-wide control, admins can combine this with managed settings (see Settings).

Example prompt

Review .claude/settings.json and our sensitive-path policy. List explicit
Read(...) denies and sandbox denyRead or credential protections that are
missing. Do not read real secret contents; inspect filenames and configuration
only.

Related