Feature Request: Zero-Trust Architecture for Environment Variable Security

[coniferconcepts]

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

# 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.