SkillByAIOpen interactive version →

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.

Figure 6.1 — Sandboxes, privileges and untrusted input.

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.