Why shall you run your coding assistant in a container​

Coding assistants have stopped being autocomplete: they now install packages, edit files and run shell commands, all with your credentials on your machine.

An agent can wipe your home directory, exfiltrate secrets, fall for prompt injection, run malicious skills, and act on irreversible operations without asking[^docker]. One may use Docker sandboxes (sbx) to run them in an isolated environment so they can work unattended. This article describes a lightweight, dependency-free alternative using only systemd, similar to the [build container][/blog/build-in-nspawn] presented earlier.

For general information about systemd-nspawn, see:

• systemd-nspawn(1) and systemd.nspawn(5) manpages
• Archlinux wiki

The container is a directory under /var/lib/machines that systemd boots. One file controls it: the nspawn config (/etc/systemd/nspawn/<name>.nspawn).

Why build in a systemd-nspawn container?​

This guide is for cross-building (e.g. Yocto) against an old distribution without touching the host. systemd-nspawn gives you:

• an old distribution, in a chroot that systemd manages for you
• fine control over resources such as CPUs and memory
• easy access to the journal from the host
• nothing more than systemd to install

This is the new site of Semalibre.