[DOCS] Security risk: Missing guidance on file permissions for `CLAUDE_ENV_FILE` persistence instructions

Resolved 💬 3 comments Opened Jan 20, 2026 by coygeek Closed Feb 28, 2026

Documentation Type

Unclear/confusing documentation

Documentation Location

https://code.claude.com/docs/en/settings#bash-tool-behavior

Section/Topic

Section: Bash tool behavior -> Option 2: Set CLAUDE_ENV_FILE before starting Claude Code (persistent environment setup)

Current Documentation

"Export the path to a shell script containing your environment setup: ``bash export CLAUDE_ENV_FILE=/path/to/env-setup.sh claude ` Where /path/to/env-setup.sh contains: `bash conda activate myenv # or: source /path/to/venv/bin/activate # or: export MY_VAR=value `` Claude Code will source this file before each Bash command, making the environment persistent across all commands."

What's Wrong or Missing?

The documentation suggests a method for environment persistence that explicitly includes export MY_VAR=value. In many developer workflows, these variables are sensitive credentials (API keys, database passwords, etc.).

The documentation fails to warn the user that if this script contains secrets and is automatically sourced by the agent, it must have restricted filesystem permissions (e.g., chmod 600). Without this warning, users may inadvertently create world-readable files containing credentials that are then automatically processed by the agent loop, increasing the risk of local credential leakage to other users or processes on the same machine.

Suggested Improvement

Add a Warning or Security Note block immediately following the example code for Option 2.

Suggested Text:

<Warning> Security Requirement: If your CLAUDE_ENV_FILE or any script it sources contains sensitive credentials (such as API keys or tokens), ensure the file has restricted permissions. Use chmod 600 /path/to/env-setup.sh to ensure only your user can read or modify the file. </Warning>

Additionally, in the export MY_VAR=value example, consider changing the variable name to something less likely to imply a secret, such as export PROJECT_STAGE=development, or explicitly label it as a potential secret location.

Impact

High - Prevents users from using a feature

Additional Context

  • Related Documentation: This connects to the security principles discussed in https://code.claude.com/docs/en/security regarding secure credential storage.
  • Example of Best Practice: Standard tools that use config files with secrets (like .ssh/config or .netrc) strictly enforce or recommend 600 permissions to prevent unauthorized access by other local users. Since Claude Code's bash tool automatically sources this file for every command, it becomes a high-value target for local exfiltration.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗