Problem
find_config_file() walks up from $PWD and honors any .dclaude file found — including one committed to a repo the user just cloned. A malicious or compromised repo can set:
GIT_AUTH=key-mount → mounts the user's ~/.ssh (private keys) into the containerMOUNT_ROOT=.. (or deeper) → widens the writable bind mount above the repo, resolved relative to the config file's directoryCA_CERT=... → injects a CA into the container's Node/TLS trustNAMESPACE=... → redirects which credential volume gets used/populated
Combined with CLAUDE_UNSAFE_TRUST_WORKSPACE=true (set in the Dockerfile, intentionally, on the premise that container isolation is the safety boundary), a repo-committed file can silently widen that exact boundary. git clone evil/repo && cd repo && dclaude is the whole attack.
Fix
direnv-style first-use approval: hash the .dclaude content; on first sight (or content change) show the parsed settings and require confirmation, recording approval in ~/.dclaude/approved-configs. Env vars set by the user keep working without prompts.
A cheaper interim step: only honor the security-sensitive keys (GIT_AUTH, MOUNT_ROOT, CA_CERT, NAMESPACE) from env vars, never from the file — or print a prominent warning showing which values came from a config file inside the repo.
Found during a full-project code review.
Problem
find_config_file()walks up from$PWDand honors any.dclaudefile found — including one committed to a repo the user just cloned. A malicious or compromised repo can set:GIT_AUTH=key-mount→ mounts the user's~/.ssh(private keys) into the containerMOUNT_ROOT=..(or deeper) → widens the writable bind mount above the repo, resolved relative to the config file's directoryCA_CERT=...→ injects a CA into the container's Node/TLS trustNAMESPACE=...→ redirects which credential volume gets used/populatedCombined with
CLAUDE_UNSAFE_TRUST_WORKSPACE=true(set in the Dockerfile, intentionally, on the premise that container isolation is the safety boundary), a repo-committed file can silently widen that exact boundary.git clone evil/repo && cd repo && dclaudeis the whole attack.Fix
direnv-style first-use approval: hash the
.dclaudecontent; on first sight (or content change) show the parsed settings and require confirmation, recording approval in~/.dclaude/approved-configs. Env vars set by the user keep working without prompts.A cheaper interim step: only honor the security-sensitive keys (
GIT_AUTH,MOUNT_ROOT,CA_CERT,NAMESPACE) from env vars, never from the file — or print a prominent warning showing which values came from a config file inside the repo.Found during a full-project code review.