Feature Request: Zero-Trust Architecture for Environment Variable Security

Summary

Implement client-side secret detection and replacement to prevent real secrets from being transmitted to Claude
Code's API, even when users explicitly read environment files.

## Problem Statement
Multiple issues have highlighted serious security concerns with Claude Code's current environment variable
handling:

• Issue #112: "Potential Security Risk: Claude Code Accessing Local .env File Environment Variables"
• Issue #401: "Claude loads my projects .env into its bash environment (!)" - User experienced unexpected

behavior when Claude automatically loaded their .env file, including dropping their local development database

• Issue #2065: "How to securely provide env variables to MCP servers?" - Users seeking secure ways to handle

secrets, noting that "env variables and code should not go together"

These issues demonstrate that the current trust-based model creates real security risks for developers.

## Current Security Model Limitations

• Relies on user awareness to avoid reading files with secrets
• Automatically loads .env files from projects (Issues #401, #112)
• Real secrets transmitted when .env files are explicitly read via tools
• Trust-based approach where users must remember what's sensitive
• No protection against accidental secret exposure

## Proposed Zero-Trust Architecture

### Client-Side Secret Protection

1. Automatic Detection: Pattern-based recognition of common secrets (API keys, tokens, connection strings)
2. Pre-transmission Replacement: Replace real values with temporary placeholders before API calls
3. Local Resolution: Real secrets only used during local execution, never transmitted
4. MCP Server Integration: Secure environment variable handling for MCP servers (addresses #2065)

### Example Flow
```bash
# Local .env.local (never transmitted)
CLOUDFLARE_API_TOKEN=real_secret_value_123abc
DATABASE_URL=postgres://user:pass@localhost:5432/db

# What Claude receives (safe for analysis)
CLOUDFLARE_API_TOKEN=<PLACEHOLDER_TOKEN_001>
DATABASE_URL=<PLACEHOLDER_DB_URL_002>

Benefits

• Solves existing security issues: Addresses concerns raised in #112, #401, #2065
• Defense in Depth: Protection even if users accidentally share sensitive files
• Enterprise Compliance: Better alignment with security policies
• Developer Experience: Focus on code without constant secret management anxiety
• Audit Trail: Clear separation of transmitted vs. local-only data
• Backward Compatibility: Existing workflows continue to work

Implementation Approaches

1. Pattern Matching: Detect common secret formats (base64, UUIDs, API key patterns, connection strings)
2. Allowlist: Only specific non-secret env vars transmitted
3. Local Execution Proxy: Sensitive operations resolved locally
4. Encrypted Secret Store: Optional integration with system keychains
5. Configuration Override: Allow users to mark specific variables as sensitive

Use Cases

• Reading configuration files for architecture analysis without exposing credentials
• Code review of deployment scripts while keeping secrets local
• Debugging environment setup issues safely
• Security audits without credential exposure
• Safe MCP server configuration (addresses #2065)

Related Issues

This proposal directly addresses security concerns raised in:

• #112 - Potential security risk with .env access
• #401 - Automatic .env loading causing issues
• #2065 - Secure environment variable management for MCP servers

This would significantly enhance Claude Code's security posture while maintaining its powerful code analysis
capabilities and solving multiple existing user-reported security issues.

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./*.pem)",
      "Read(./*.key)",
      "Bash(printenv)",
      "Bash(export)"
    ]
  }
}