Pinned toolchain images were the easy part; scoping the agent is the new build problem

Docker has published an ESP32 firmware walkthrough that treats reproducible builds as a solved problem and spends its argument on a newer one: what an AI coding agent is permitted to touch while it works on your firmware ^[1]. The company frames the official `espressif/idf` image as the fix for reproducibility and its Sandboxes product, the `sbx` CLI, as the fix for agents ^[2].

The baseline is familiar discipline. The `espressif/idf` image ships a complete, pinned ESP-IDF installation, including the framework, the Xtensa and RISC-V toolchains, the Python environment, CMake and ninja, so a build is one `docker run` invocation ^[3][4]. The operational details are the usual ones: run as your own UID so artifacts in `build/` are not owned by root, set `HOME=/tmp` so the tools have a writable cache, and whitelist the mounted path with `IDF_GIT_SAFE_DIR` when Git complains about dubious ownership ^[5][6]. Docker's tag guidance is the part worth copying into a policy document: `latest` tracks master and will eventually break you, `release-vX.Y` picks up bugfixes on a release branch, and exact `vX.Y.Z` tags are the safest choice for products in maintenance ^[7]. Turning on ccache and persisting it in a volume takes full rebuilds of a mid-size project from minutes to seconds ^[8]. Hide the whole thing behind a Makefile and switching toolchains becomes one variable ^[9]. Because containers are isolated, two IDF versions can drive two boards on one machine at the same time ^[10].

None of that is new. The shift is in what the second half is defending against. A pinned image constrains the inputs to a build; it says nothing about the reach of a process that is writing the code. According to Docker, Sandboxes exist to let coding agents work at full speed "without giving them the keys to your laptop," and to make unsupervised AI sessions safe ^[2][11]. That is a blast-radius claim, not a determinism claim, and it is the vendor's own.

The interesting tension is hardware. Docker Desktop cannot pass USB devices into containers on macOS or Windows, so the post routes the serial port over the network using RFC2217, which esptool supports natively, and points `idf.py` at `rfc2217://host.docker.internal:4000` ^[12][13][14]. Docker calls this the linchpin: once the port is a network endpoint, containers, CI runners and sandboxed agents can all reach it ^[15]. The consequence follows directly. A sandbox that isolates the filesystem does not isolate a TCP port, and anything that can open that port can flash the board ^[16]. The excerpt of the walkthrough available here stops in Part 2, before the sandbox permission model is described, so how `sbx` scopes network egress is not established by this material ^[17].

Watch whether sandbox tooling grows the same explicitness that container tags did: default-deny egress, per-session allowlists, and an answer for the serial bridge specifically. Watch, too, whether teams that already pin `vX.Y.Z` for maintenance firmware start pinning what an agent may reach with the same care, because a flashing endpoint reachable from an unsupervised session is a production risk, not a developer-convenience one ^[7][11][15].