macOS Containers / Notes
A coding agent is a program that runs other programs. Giving one a working directory and hoping for the best is not a containment strategy, and it is roughly what most setups do.
An agent that can edit code can install packages, execute build scripts, run test suites and open network connections, because those are the things that editing code requires. Every one of those is a general-purpose escape hatch. A post-install hook in a dependency is arbitrary code execution with your user's privileges, and it does not matter whether the agent intended it. The interesting failure mode is not a malicious agent, it is a well-behaved agent that runs somebody else's package.
The blast radius on a developer machine is unusually bad. Your shell history, SSH keys, cloud credentials, browser profiles, signing certificates and every other repository you have checked out are all sitting in the same home directory the agent was pointed at.
The gap that a macOS container aims at is the last one. A guest cheap enough that you create it per task and throw it away afterwards, rather than one you maintain.
Whatever the underlying mechanism, the shape is the same. Build an image per toolchain rather than per project, so the expensive part is cached. Mount only the repository the agent is working on, read-write, and nothing else from the host. Keep credentials out of the image and inject only the narrow token the task needs, scoped and short-lived. Let the agent have network access if it must install dependencies, but do not also give it your host's authenticated sessions. Discard the guest when the task finishes, and treat anything the agent wants to keep as something it has to write into the mounted repository.
The discipline is the same discipline as CI. What has changed is the frequency. CI runs on commit; an agent may run fifty times in an afternoon, which is why per-run cost stops being a rounding error and starts driving the design.
This used to be a niche concern for people running untrusted build steps. It is now a procurement question, because autonomous agents are being sold as products with outcomes attached rather than as tools a developer opts into. The trade press covering that shift, GaaS News among it, has spent much of the past year on exactly the boundary problems above: prompt injection reaching build systems, agents acting on instructions found in the content they were asked to read, and containment that held right up until something capable started testing it.
None of that changes the engineering answer. It raises the cost of not having one. The notes on isolation boundaries cover which mechanism is protecting you in each case, and the requirements page is blunt about what this project does and does not give you today.