#8161: fix(sandbox): block dangerous environment variables from Docker containers

## Summary Block dangerous environment variables from being passed to Docker containers via `docker exec -e` to prevent code injection attacks. ## The Problem The `buildDockerExecArgs()` function passes all user-controlled environment variables directly to `docker exec -e` without filtering dangerous variables like `NODE_OPTIONS`, `LD_PRELOAD`, or `DYLD_INSERT_LIBRARIES`. Users can inject these variables into Docker containers through config or skill environment settings (VULN-159, VULN-160), potentially enabling container code execution or escape. For example, with a malicious config: ```json { "env": { "vars": { "LD_PRELOAD": "/workspace/malicious.so" } } } ``` The `LD_PRELOAD` value would be passed to the Docker container, potentially enabling shared library hijacking inside the container. ## Changes - `src/agents/bash-tools.shared.ts`: Added blocklist for dangerous environment variables and pattern matching for `LD_*` and `DYLD_*` prefixes in `buildDockerExecArgs()` - `src/agents/bash-tools.test.ts`: Added tests verifying blocked variables and allowing safe variables ### Blocked Variables - **Node.js injection**: `NODE_OPTIONS`, `NODE_PATH`, `NODE_REPL_HISTORY` - **Linux library injection**: `LD_PRELOAD`, `LD_LIBRARY_PATH`, `LD_AUDIT`, and all `LD_*` - **macOS library injection**: `DYLD_INSERT_LIBRARIES`, `DYLD_LIBRARY_PATH`, and all `DYLD_*` - **Python injection**: `PYTHONPATH`, `PYTHONSTARTUP`, `PYTHONHOME` - **Perl injection**: `PERL5LIB`, `PERLLIB`, `PERL5OPT` - **Ruby injection**: `RUBYLIB`, `RUBYOPT` - **Shell injection**: `BASH_ENV`, `ENV` Note: `PATH` is explicitly allowed as it's used for the custom PATH prepending logic in the existing code. ## Test Plan - [x] `pnpm build && pnpm check && pnpm test` passes - [x] New test `describe('buildDockerExecArgs env var blocking')` validates the fix - [x] Verified dangerous variables are silently blocked - [x] Verified safe variables (API keys, custom vars) still work - [x] Verified PATH is still passed for custom PATH handling ## Related - [CWE-74](https://cwe.mitre.org/data/definitions/74.html) - Improper Neutralization of Special Elements in Output - Internal audit ref: VULN-161 --- *Built with [bitsec-ai](https://github.com/bitsec-ai). AI-assisted: Yes. Testing: fully tested (test written before fix). Code reviewed and understood.* <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR hardens the Docker-based bash sandbox by filtering user-controlled environment variables before passing them to `docker exec -e`. It introduces a blocklist (plus `LD_*`/`DYLD_*` prefix blocking) in `buildDockerExecArgs()` and adds unit tests to assert that high-risk injection variables are dropped while normal variables (including `PATH` for the existing PATH-prepend logic) continue to work. This fits into the sandbox execution path by ensuring the env forwarded into the container can’t be used to change dynamic linker / interpreter behavior (e.g., preload libraries or inject runtime flags) at process start. <h3>Confidence Score: 4/5</h3> - This PR is reasonably safe to merge and materially improves sandbox safety, with one correctness gap around case-normalization of blocked env var names. - Change is localized to argument construction and covered by unit tests, but the current implementation can miss mixed-case variants for exact-name blocked variables (Set lookup is case-sensitive). - src/agents/bash-tools.shared.ts (env var normalization logic) <!-- greptile_other_comments_section --> <!-- /greptile_comment -->