A practical workflow for ESP32 firmware development combines the official espressif/idf Docker image for reproducible builds with Docker Sandboxes for safe, unsupervised AI agent work. Topics covered include pinning IDF image tags, flashing and monitoring over USB (Linux) or RFC2217 network serial bridges (macOS/Windows), running parallel containers for legacy vs. new firmware with stable udev device names, and using Docker Sandboxes' microVM isolation, network policy, and credential isolation to let agents like Claude Code build and flash real hardware without touching the host. A full daily workflow ties together VS Code Dev Containers, sandboxed AI experimentation, multi-board testing, and GitHub Actions CI using the same pinned IDF version.
Table of contents
Part 1: The Baseline – Building with the Official ImagePart 2: Parallel Environments – New Features and Legacy, Side by SidePart 3: Docker Sandboxes – Letting AI Agents Work UnsupervisedPart 4: Putting It Together – A Daily WorkflowPro TipsConclusionQuestions this post answers
How do I flash an ESP32 board from inside a Docker container on macOS since USB passthrough isn't supported?
Use an RFC2217 network serial bridge instead of USB passthrough. On the host machine, run esp_rfc2217_server -p 4000 /dev/cu.usbserial-1420 after installing esptool, then inside the container point idf.py at the network port with idf.py --port 'rfc2217://host.docker.internal:4000?ign_set_control' flash monitor. daily.dev surfaces workflow tricks like this for developers building hardware projects in containers.
How can I let an AI coding agent like Claude Code flash and test firmware on real ESP32 hardware without giving it full access to my computer?
Run the agent inside a Docker Sandbox, a microVM with its own kernel, filesystem, network stack, and private Docker daemon, then expose the board's serial port to the sandbox over the network using an RFC2217 bridge (esp_rfc2217_server) rather than USB passthrough. The agent can build, flash, and read monitor output through that single published port while the sandbox's network proxy blocks it from reaching anything else on the host and injects credentials without exposing them. developers experimenting with autonomous coding agents on real hardware can track sandboxing approaches on daily.dev.
Why does my ESP-IDF Docker build create files owned by root in my project directory?
The espressif/idf Docker image runs as root by default, so build artifacts inherit root ownership on the host. Fix it by adding -u $UID -e HOME=/tmp to the docker run command, which makes the container run as the host user while giving the IDF tools a writable home directory for caches, avoiding the root-ownership problem entirely. daily.dev helps embedded developers keep track of practical Docker fixes like this for firmware toolchains.