Running OpenCode (and Other) Agentic Coding Tools in Apple Containers
Warning: I am not a security expert. Here I am simply documenting how I do things.
The Illusion of Local Agent Safety
Agentic coding tools like little-coder and OpenCode operate by turning natural language instructions into file manipulations and shell commands. When run natively on macOS (”bare-metal”), you are executing an autonomous loop with your user-level permissions. If the underlying LLM hallucinates an invalid flag, executes a destructive shell payload, or triggers an unintended recursive path deletion, the blast radius is your entire user directory.
Furthermore, these agents pull down third-party dependencies, ingest arbitrary markdown documentation, and read unverified source code. This exposes your native environment to direct prompt injection and supply chain attacks: an adversarial payload in a repository’s README.md can hijack the agent’s tool-calling mechanism to execute arbitrary bash commands, extract ~/.ssh/id_rsa, or plant a persistent background daemon.
Isolated local accounts offer weak mitigation. While they restrict access to primary iCloud data, they still share the host kernel and local network. True containment requires a virtualization boundary. Apple’s native container virtualization framework provides the exact sandboxing mechanism required to execute untrusted agentic actions without risking host OS compromise.
UPDATE July 8, 2026: the Davit app provides a UI for using Appe containers https://davit.app/
The Containment Blueprint: Apple Containers
To isolate your coding agents, use the Apple Containers environment (https://github.com/apple/container).
By containerizing the agent execution loop, arbitrary bash actions and file system mutations are fully bound within an unprivileged Ubuntu virtualization layer.
The following configurations adapt this setup for OpenCode and little-coder, enforcing a minimal dependency footprint.
The Minimized Dockerfile
This configuration restricts the execution environment to the baseline primitives requested: npm, opencode, and headless Emacs (emacs-nox), alongside the mandatory Apple host-integration systemd patches. I put this Dockerfile in the directory ~/GITWORK where I keep projects I want to develop with OpenCode.
Dockerfile:
FROM ubuntu:24.04
ENV container container
# 1. Install base OS management dependencies and headless Emacs
RUN apt-get update && \
apt-get install -y \
dbus systemd openssh-server net-tools iproute2 iputils-ping \
curl wget vim-tiny man sudo pciutils zstd build-essential gnupg \
emacs-nox
# 2. Inject NodeSource PPA and install Node.js 22 + npm
RUN curl -fsSL https://deb.nodesource.com/setup_22.x | bash - && \
apt-get install -y nodejs
# 3. Install agentic tools globally (Fixed package name from opencode to opencode-ai)
RUN npm install -g opencode-ai little-coder
# Clean up apt caches to minimize image size
RUN apt-get clean && rm -rf /var/lib/apt/lists/*
# 4. Systemd configuration for Apple Host Integration
RUN >/etc/machine-id && >/var/lib/dbus/machine-id
RUN systemctl set-default multi-user.target
RUN systemctl mask \
dev-hugepages.mount \
sys-fs-fuse-connections.mount \
systemd-update-utmp.service \
systemd-tmpfiles-setup.service \
console-getty.service
RUN systemctl disable networkd-dispatcher.service
RUN sed -i -e ‘s/^AcceptEnv LANG LC_\*$/#AcceptEnv LANG LC_*/’ /etc/ssh/sshd_config
Provisioning and Execution Workflow
Build and Initialize the Machine
Initialize the engine framework and compile your OCI-compliant image locally via the host terminal.
Run this in the directory that you want mounted as ./workspace in the container. I Have a local directory GITWORK with the git projects I want to work on and run the following from ~/GITWORK:
# Initialize the container system
container system start
# Compile the minimized OCI image
container build -t local/agent-machine:latest .
# Provision the virtual instance
container machine create local/agent-machine:latest --name agent-env
container machine set -n agent-env cpus=4 memory=10G
# Shut down the container system
container system stop
When the container runs, on my system ~/GITWORK is mounted inside the container.
Sandbox Execution Loop
To drop into the isolated environment and execute your agent safely, manage the instance runtime via the following sequence:
# Initialize the container system
container system start
# Boot the micro VM and drop into the interactive environment
container machine run -n agent-env
# run inside the container, you are in the mounted local directory...
# ...
# To exit the sandboxed shell when execution tasks complete:
exit
# Hard-stop the underlying kernel instance from macOS host
container machine stop agent-env
container system stop
Lifecycle and Storage Management
Virtualized development environments accumulate stale state and layers over time. To ensure clean-slate reproducibility and reclaim host disk capacity, tear down the virtual resources completely using the sequence below:
# 1. Halt the execution runtime
container machine stop agent-env
# 2. Destructively remove the virtual machine definition
container machine rm agent-env
# 3. Purge the compiled OCI layers from disk
container image rm local/agent-machine:latest
Wrap Up
Utilizing this pipeline helps to isolate destructive tool actions within the Apple Container boundary, maintaining zero-trust parity for local agent execution.