Refuse to dump contents of likely-secret files (.envrc, .env, ~/.ssh/*, etc.) by default

Problem

When Claude cats or Reads a file, the contents become part of the conversation context that is transmitted to Anthropic. For files that typically hold secrets — .envrc especially — this leaks credentials off the user's machine into transcript storage, even though the file itself never left the laptop.

Example from a real session: I asked Claude to publish a Ruby gem to RubyGems. It found my GEM_HOST_API_KEY by running cat .envrc, which also pulled my Docker Hub PAT into the transcript. The gem push succeeded, but two production tokens are now in transcript logs that did not need to be.

.envrc (direnv) is the cleanest case — it almost always holds secrets, since the entire reason to use direnv over .env is to keep machine-specific credentials out of source-controlled config. .env is more mixed, but still risky enough to warrant the same default.

Proposed behavior

Claude Code should refuse, by default, to dump the full contents of a curated list of secret-bearing files via Read or shell tools (cat, head, tail, etc.):

• .envrc, .env, .env.*
• ~/.netrc, ~/.gem/credentials, ~/.pypirc
• ~/.ssh/* (excluding *.pub)
• *.pem, *.key, *.p12, config/master.key
• credentials.json, service-account*.json, *.kubeconfig

Instead, Claude should:

• source <file> && <cmd> so the secret enters env, not stdout
• grep -o '^export [A-Z_]*' <file> for names-only inspection
• Or ask the user to run the secret-consuming command themselves

Opt-out: explicit user request ("show me the .envrc") overrides the default, after a transcript-leak warning.

Why a product default vs. a user CLAUDE.md rule

Users can add this rule to their personal ~/.claude/CLAUDE.md, but:

1. New users will not have the rule until they get burned once.
2. The risk is uniform across users — anyone with .envrc likely has secrets in it.
3. This is exactly the kind of safe default the harness can enforce more reliably than a prompt-level instruction can.