What happens when you give an open-weights 4B parameter language model root access to a broken Linux server and tell it to fix the problem?
I built local-agent-sandbox, a lightweight evaluation harness running on pure QEMU and llama.cpp. Here is how the experiment was structured, how the sandboxing works, and how the model performed.
Most LLM agent sandboxes default to Docker. While containers are great for application packaging, they are not security boundaries:
Instead, I used pure QEMU with KVM and QCOW2 Copy-On-Write Overlays:
`ubuntu-base.qcow2`) contains a clean headless Ubuntu 24.04 install.` qemu-img create -f qcow2 -b ubuntu-base.qcow2 -F qcow2 sandbox.qcow2`
`gemma-4-E4B-it-qat-UD-Q4_K_XL` (Google Gemma 4B quantized)`llama.cpp` (`llama-server` with `--jinja` tool calling)`127.0.0.1:2222`
We tested 3 distinct DevOps failure modes:
systemctl status nginx, noticed the socket couldn't bind, checked lsof -i :80, extracted the PID ( 892), ran kill -9 892, and started Nginx cleanly./var/www/html/index.nginx-debian.html was set to chmod 000. ls -la /var/www/html and accurately printed ---------- 1 root root. But instead of modifying permissions ( chmod 644), it ran chown -R www-data:www-data. When curl -I still returned 403, it assumed Nginx routing was broken and spent the next 5 turns rewriting virtual hosts with sed until it ran out of turns.nginx -t, inspected configuration, checked status, and ensured traffic on port 80 was restored.
Full code, setup instructions, and raw execution logs are open source:
👉 [https://github.com/Chetan0246/local-agent-sandbox](https://github.com/Chetan0246/local-agent-sandbox)