Context
We currently use a PreToolUse hook (hooks/allow-venv-source.sh) to auto-approve
source .venv/bin/activate commands that trigger Claude Code's hardcoded eval-like
builtin safety warning. The hook works but runs on every Bash call and requires
pattern matching against the command string.
Alternative: CLAUDE_ENV_FILE
Claude Code supports a CLAUDE_ENV_FILE environment variable that points to a shell
script sourced before every Bash command. If it contains venv activation, Claude never
generates source .venv/bin/activate at all, so the safety warning never fires.
A CwdChanged hook could auto-detect .venv/ per project and populate the env file
dynamically. This would eliminate both the allowlist entry and the PreToolUse hook.
Why deferred
The current hook approach works, deny rules backstop it, and the pattern was tightened
by codereview. Switching to CLAUDE_ENV_FILE is a cleaner architecture but a separate
piece of work.
References
Context
We currently use a PreToolUse hook (
hooks/allow-venv-source.sh) to auto-approvesource .venv/bin/activatecommands that trigger Claude Code's hardcoded eval-likebuiltin safety warning. The hook works but runs on every Bash call and requires
pattern matching against the command string.
Alternative: CLAUDE_ENV_FILE
Claude Code supports a
CLAUDE_ENV_FILEenvironment variable that points to a shellscript sourced before every Bash command. If it contains venv activation, Claude never
generates
source .venv/bin/activateat all, so the safety warning never fires.A
CwdChangedhook could auto-detect.venv/per project and populate the env filedynamically. This would eliminate both the allowlist entry and the PreToolUse hook.
Why deferred
The current hook approach works, deny rules backstop it, and the pattern was tightened
by codereview. Switching to CLAUDE_ENV_FILE is a cleaner architecture but a separate
piece of work.
References
hooks/allow-venv-source.shzat.env-install.sh