Lesson 17 / 25
Sandboxed Execution
Run untrusted code where it cannot hurt.
Containers, no secrets, limited network
A fixer runs code it has just changed, plus whatever the tests execute, so treat it as untrusted code execution. Use disposable containers or VMs with: a copy of the repository only, no production credentials, restricted or no network access (allow only the package mirror if needed), CPU, memory and time limits, and a non-root user. Destroy the environment after each run. This contains both honest mistakes and malicious code introduced through dependencies or injected instructions.
Contain the fixer
Run fixers with the least access needed, isolated from production and from untrusted instructions.
A sandbox run (sketch)
Docker flags that restrict an auto-fix job. Not run here.
docker run --rm \
--network none \
--user 1000:1000 \
--memory 2g --cpus 2 --pids-limit 256 \
--read-only --tmpfs /tmp \
-v "$PWD/worktree:/work:rw" -w /work \
python:3.12-slim \
sh -c "pip install --no-index --find-links /wheels -r requirements.txt && python -m pytest -q"Pre-fetch dependencies
Download packages into a local mirror before the sandbox starts, so test runs can work with networking disabled.
Quick check: Why disable network access in a fix sandbox?
- It makes git faster
- Tests never need files
- To stop exfiltration and unexpected downloads by untrusted code
- Containers require it
Answer
To stop exfiltration and unexpected downloads by untrusted code — Contain what you cannot fully trust.