# Sandboxed Execution — Safe Autonomous Code Fixing

Source: https://www.skillbyai.com/en/safe-autonomous-code-fixing/x-sandbox

> 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.

![Three ideas: sandboxes, least privilege, untrusted input.](assets/figures/safe-autonomous-code-fixing/section-6-map.svg) — Figure 6.1 — Sandboxes, privileges and untrusted input.

## A sandbox run (sketch)

Docker flags that restrict an auto-fix job. Not run here.

```bash
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.

**Quiz:** Why disable network access in a fix sandbox?

- [ ] It makes git faster
- [ ] Tests never need files
- [x] 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.