Remi d'Almeida7 min readYOLO Mode Without Handing an AI Agent My Laptop
Why I run every Aitopus coding-agent session inside a Docker Sandbox and use a reusable project kit to make a complex native setup routine.
On this page
The most capable coding agents are also the most frustrating when they stop every few seconds to ask whether they may run a command.
Install this package? Yes. Run the tests? Yes. Let a build script invoke another build script? Yes.
Eventually, the temptation is obvious: enable “YOLO mode” and let the agent work.
On my laptop, however, that combines two separate decisions:
- I want the agent to work without waiting for me.
- I am willing to give it everything my user account can reach.
I agree with the first statement. I do not agree with the second.
Building Aitopus keeps one question constantly in view: where does an AI process run, and what is it allowed to touch? I apply the same question to my development environment.
That is why every coding-agent session I run for the project starts inside a Docker Sandbox. Aitopus has a substantial Rust codebase and a demanding native build environment, so the agent needs to install dependencies, compile code, run tests, and execute scripts without running unrestricted on my laptop.
The workflow has four boundaries: isolate the agent in a microVM, choose how the repository is shared, restrict network access, and review the result as untrusted code.
Why not just use a container?
A normal development container is useful for packaging dependencies, but it is not automatically a strong security boundary.
The common shortcut is to mount the host Docker socket so a tool inside the container can build and run other containers. That effectively gives the tool control over the host Docker daemon. For an autonomous agent, this undermines much of the intended isolation.
Docker Sandboxes take a different approach. Each sandbox runs inside a microVM with its own Linux environment, filesystem, network, and Docker Engine.
Inside that environment, the agent can:
- install packages with
sudo - build images
- start containers
- run Docker Compose
- change its development environment
It can do those things without receiving access to the host Docker daemon or files outside the workspace I deliberately share.
The promise is not that the agent cannot cause damage. The promise is that its blast radius is smaller and easier to understand.
Direct and clone modes
Docker Sandboxes support two useful ways to share a project.
Direct mode
The project is mounted read-write. Changes made by the agent appear immediately in my local checkout. I use this for ordinary development because the agent and I can work against the same files.
The tradeoff is clear: the repository remains inside the blast radius.
Clone mode
For unfamiliar agents, destructive experiments, or parallel work, clone mode provides a stronger boundary. The host repository is mounted read-only, while the agent works inside a private clone in the sandbox. Changes do not reach the local checkout until they are explicitly brought back.
Clone mode protects the repository from modification, not inspection. Files inside the repository, including ignored files, may still be visible through the read-only mount. Secrets therefore stay outside the workspace.
The reusable project kit
A blank sandbox solves isolation. It does not solve setup.
I did not want every new session to begin with a long explanation of which native libraries the project requires, which toolchain versions the build expects, or how the local-model environment should be configured.
Docker Sandboxes support reusable project configurations called kits. My project kit records the tools and environment the agent needs, including:
- native build dependencies
- Rust tooling
- browser-testing dependencies
- environment variables
- the network access required during setup
The exact configuration matters less than the principle: setup knowledge is stored with the project instead of being reconstructed from memory.
An AI agent can draft a project-specific spec.yaml by inspecting the repository and asking about what it cannot infer: system packages, build and test commands, background services, network access, ports, and host-managed credentials.
For a web app, that may include Playwright and a headless browser inside the sandbox so the agent can render pages, run end-to-end tests, and capture screenshots for visual review. If the selected agent and model support image input, it can inspect those screenshots too.
The generated file still needs review and validation with sbx kit validate.
It is also a troubleshooting notebook
The first version of the kit was much smaller. It grew whenever reality contradicted an assumption.
One version replaced PATH instead of extending it. That removed paths added by the sandbox runtime and prevented the coding agent from starting correctly.
Another version set RUSTFLAGS globally. That accidentally replaced a project-specific CI flag used to exclude tests that contact live model providers.
Those problems could have remained in shell history or personal notes. Instead, their fixes now live beside the configuration they explain.
That is the deeper value of the kit. It does not merely install software. It turns environment knowledge into project code that can be reviewed, versioned, and improved.
The daily workflow
For normal development, I create a named sandbox with the project kit:
# Other supported agents include claude, gemini, and opencode.
sbx run codex \
--name aitopus \
--kit ./sandbox/aitopus/
This uses the direct project mount, so the agent’s edits appear in my working tree.
When a stronger boundary is needed, a separate sandbox can instead be created in clone mode:
sbx run --clone --no-share-skills codex \
--name aitopus-review \
--kit ./sandbox/aitopus/
The first setup can be substantial because the environment includes native toolchains, browser binaries, and build dependencies. The advantage is that sandbox state and build caches persist between sessions.
After the initial setup, I can reconnect to the named sandbox rather than rebuilding the environment from scratch.
Set network access deliberately
A coding agent still needs the internet. It may need its model provider, package registries, source repositories, and release archives.
For more sensitive sessions, I start with a restrictive network policy and allow only the services required by the agent and the build.
The credential proxy provided by Docker Sandboxes can keep supported credentials on the host and attach them to approved requests. This is preferable to copying a long-lived API key into the sandbox and later forgetting where it was stored.
Network controls still have limits. An approved service can receive information the agent sends to it. Restricting destinations reduces exposure; it does not make every outbound request appropriate.
What the sandbox does not solve
A sandbox limits access; it does not guarantee correct code. I review the agent’s output as though it came from an untrusted pull request.
- Correctness. The agent can still introduce a vulnerable dependency, misunderstand a requirement, or produce code that passes tests while violating the intended design.
- Host-side effects. In direct mode, the agent may change more than ordinary source files. Git hooks, CI workflows, IDE tasks, build scripts, and agent configuration can all execute code later on the host.
- Repository changes. Clone mode prevents direct writes to the host checkout, but anything brought back still requires review.
- Target platforms. A Linux sandbox is a safer and more consistent workbench, not proof that the finished application is correct on every target platform.
Autonomy belongs in the environment
Permission prompts are useful when there is no stronger boundary. They are a poor substitute for designing one.
Inside a dedicated microVM, the agent can be aggressive. It can install compilers, change packages, build containers, and work through an entire debugging loop without waiting for approval after every command.
I deliberately give it the project repository. I do not give it the host Docker daemon, unrelated files, or unrestricted access to the rest of my machine.
The result is not only safer. It is more productive.
I spend less attention approving routine actions, less time repairing local toolchains, and less prompt space explaining the development environment. The agent gets enough freedom to work; I get a boundary I can inspect.
The same principle applies to local AI: choose where computation runs, decide what information may cross the boundary, and keep the rest under local control.
That is the version of YOLO mode I am comfortable with:
not blind trust in an agent, but confidence that I chose where its mistakes are allowed to land.
Note: Docker Sandboxes kits are currently experimental. Check the current documentation before relying on specific commands or configuration fields in a production workflow.