[FEATURE] Mark sensitive environment variables and file paths to prevent secret exposure

[patons02]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

Claude Code can access secrets through multiple vectors that existing mitigations don't cover:

File reads - .claudeignore and permission hooks are bypassed via system reminders (#8031) and indexing (#4160). In one case Claude read .env.local and committed the values to an env.example file that was pushed to git (#7921).

Shell environment - env, printenv, or echo $VAR exposes any exported variable regardless of file protections. Even when using external secret managers (1Password CLI, HashiCorp Vault, AWS SSM etc.) to keep secrets off disk, once values are resolved into the shell environment they're fully visible.

Aggressive debugging - Claude hunts for credentials when troubleshooting auth errors and injects them into curl commands (#9637).

Current workarounds like .claudeignore, permission hooks, and per-command wrapping with op run are either incomplete (only covering file access, not shell environment) or too restrictive (limiting Claude's ability to help with debugging).

Proposed Solution

A single sensitive config in .claude/settings.json that lets users mark env var names and file paths as sensitive. Claude sees they exist but never sees the values/contents.

{
  "sensitive": {
    "envPatterns": ["*_TOKEN", "*_KEY", "*_SECRET", "*_PASSWORD", "*_API_*"],
    "paths": [".env.local", ".env.production", "secrets/", "*.pem", "*.key"]
  }
}

Env var behaviour - when Claude encounters a matching variable via shell output, file read, or system reminder:

STRIPE_SECRET=*****
DATABASE_URL=*****
NODE_ENV=development     // not matched, visible as normal

File/directory behaviour - matched paths are fully blocked from context injection. Unlike .claudeignore (which only prevents indexing), this filter applies to all access vectors including system reminders, indirect reads, and command output like cat .env.local. Claude sees the file/directory exists (so it can reference it in scripts or configs) but never sees the contents.

The filter applies at the context injection boundary - glob match on variable names and file paths, redact/block before anything enters Claude's context. No secret detection heuristics, no proxy architecture, no specific tool integrations required.

Alternative Solutions

• .claudeignore - only prevents indexing, bypassed via system reminders ([BUG] Claude Code could read the .env content even .claude/settings.json is configured #8031) and indirect access (Support ".claudeignore" file to prevent secret exposure #4160)
• Permission hooks - can deny file reads but don't cover shell environment access, and Claude can still see file contents via system reminders
• op run per-command - secrets only exist in child process, but this limits Claude to running individual wrapped commands rather than freely debugging
• Not exporting secrets - breaks tooling that depends on env vars
• Feature Request: Zero-Trust Architecture for Environment Variable Security #2695 proposed a "Zero-Trust Architecture" with pattern-based secret detection, placeholder replacement, local execution proxies, and encrypted stores - far more complex than needed

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

1. I'm working on a Node.js app that uses Stripe, a database, and various third-party APIs
2. My .env.local has raw credentials; my .zshrc exports API keys via op read
3. I ask Claude Code to debug a failing API call
4. Claude runs env | grep STRIPE or cat .env.local to find credentials and stuffs them into a curl command - now my secrets are in Claude's context
5. With this feature, I'd add "sensitive": { "envPatterns": ["*_KEY", "*_SECRET", "*_TOKEN"], "paths": [".env.local", "*.pem"] } to my .claude/settings.json
6. Claude would see STRIPE_SECRET=***** and know the variable is configured without ever seeing the value
7. Claude could still help debug by checking the variable exists, verifying the format of non-sensitive config, and suggesting fixes - just without accessing the actual secret

Additional Context

Related issues showing this is a recurring problem:

• Feature Request: Zero-Trust Architecture for Environment Variable Security #2695 - Zero-trust env var architecture (open, 9 upvotes, proposes a more complex version of this)
• [BUG] Claude Code AGGRESSIVELY reads secrets out of .env files and leaks them to your servers in so doing #9637 - Claude aggressively reads secrets from .env files
• [Bug] Critical Security Vulnerability: Unauthorized .env File Access #7921 - Claude committed .env.local secrets to git via env.example
• [BUG] Claude Code could read the .env content even .claude/settings.json is configured #8031 - System reminders bypass .env read permissions
• Support ".claudeignore" file to prevent secret exposure #4160 - .claudeignore insufficient - Claude finds indirect access routes
• Secure env variables by adding .claudeignore #2637 - Original .claudeignore for env files request
• Potential Security Risk: Claude Code Accessing Local .env File Environment Variables #112 - .env file access security risk
• [BUG] Claude loads my projects .env into its bash environment (!) #401 - Automatic .env loading into bash environment

This proposal consolidates these into one focused, minimal solution: glob patterns on var names and file paths, filtered at the context boundary. Tool-agnostic, composable with existing workarounds, and simple enough to ship without major architectural changes.

[github-actions]

Found 3 possible duplicate issues:

1. Read deny permissions in settings.json not enforced for .env files #24846
2. [BUG] <system-reminder> can read sensitive selected text from .env files, no hooks available to protect our files #20305
3. [BUG] Claude Code reads .env files and hardcodes secrets into inline scripts #24185

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[zhanglin2603]

Hi team, I read through #25053 and I can own this.

• My read: this is primarily a core implementation task tied to "[FEATURE] Mark sensitive environment variables and file paths to prevent secret exposure".
• I will focus on these issue-specific points first: feature, mark, sensitive.
• First I will reproduce and confirm expected behavior for the core implementation path.
• Then I will implement the fix with targeted tests and keep scope tight (good confidence).
• I will share a working PR update fast (24h for first patch, 48h for final polish) with verification notes.
  If this approach works for you, I can start now.

[chandika]

+1, this should exist.
I’d treat it as layer 1, not final layer.

Why: path/var controls reduce acquisition, but don’t protect what already entered context in prior turns. You still need a provider-boundary control.

We run this as a second layer in front of provider calls:
https://github.com/chandika/mirage-proxy

[moukrea]

I ran into most of these and ended up building an external tool to work around them while waiting for a native solution.

opaq (github.com/moukrea/opaq) takes the approach of keeping secret values away from the agent entirely:

• Secrets stored in an age-encrypted store, master key in OS keychain
• opaq search <query> returns names + descriptions, not values
• opaq run -- <command with {{PLACEHOLDER}}> resolves tokens at child process spawn
• stdout/stderr filtered with Aho-Corasick (raw, URL-encoded, base64, shell-escaped)
• Files written during execution get scrubbed

There's also a Claude Code plugin (github.com/moukrea/claude-code-plugins) with hooks that block store access, auto-wrap {{SECRET}} commands, and prevent writing placeholders to files.

Doesn't replace the need for a native sensitive config — would love to see that land too. But this covers file reads, shell env, and command output today.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.