#8186: fix(sandbox): validate setupCommand to prevent shell injection

## Summary Add validation to the Docker sandbox `setupCommand` configuration to prevent command injection attacks. ## The Problem The `setupCommand` configuration value is passed directly to `sh -lc` inside Docker containers without any validation or sanitization. An attacker who can modify the configuration (via `config.patch`, file write access, or compromised credentials) could inject arbitrary shell commands that execute during container initialization. This is particularly dangerous because: - Commands run as root inside the container - Workspace volumes are often mounted with write access - The container has network access by default - Commands execute before any user code runs Reference: [CWE-78: OS Command Injection](https://cwe.mitre.org/data/definitions/78.html) ## Changes - `src/agents/sandbox/docker.ts`: Add `validateSetupCommand()` function that checks for dangerous patterns including: - Command chaining operators (`;`, `&&`, `||`) - Command substitution (backticks, `$()`) - Pipes and redirections (`|`, `>`, `>>`, `<`) - Subshell syntax - Dangerous commands (`curl`/`wget` with URLs, `eval`, `nc`/`netcat`) - Shell invocation with command strings (`bash -c`, `sh -c`, `zsh -c`) - Multi-line commands (newlines) - `src/agents/sandbox/docker.setup-command-validation.test.ts`: New test file with 18 test cases covering the validation logic ## Test Plan - [x] `pnpm build && pnpm check && pnpm test` passes - [x] New test `describe('VULN-050: sandbox setupCommand validation')` validates the fix - [x] Valid setup commands like `apt-get update`, `pip install requests` are allowed - [x] Dangerous patterns are rejected with clear error messages ## Related - [CWE-78: OS Command Injection](https://cwe.mitre.org/data/definitions/78.html) - Internal audit ref: VULN-050 --- *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 adds a `validateSetupCommand()` gate before executing Docker sandbox `setupCommand` via `sh -lc`, along with a new Vitest suite covering common shell-injection metacharacters and a few high-risk utilities. The change fits into the sandbox container creation flow (`createSandboxContainer` in `src/agents/sandbox/docker.ts`) by failing fast with a clear error message when the configured setup command contains denied patterns, preventing multi-command/chaining and command-substitution payloads from being executed during container initialization. <h3>Confidence Score: 3/5</h3> - This PR improves security, but a couple of deny patterns are likely to break benign setups or behave inconsistently. - Core logic is straightforward and covered by tests, but the unconditional `(` ban is overly broad and likely to reject legitimate commands, and there are redundant/inconsistent `wget`/`curl` rules that suggest the validation policy may not match the intended behavior. - src/agents/sandbox/docker.ts (denied patterns); src/agents/sandbox/docker.setup-command-validation.test.ts (test descriptions vs behavior) <!-- greptile_other_comments_section --> <!-- /greptile_comment -->