I wanted OpenCode to have more freedom—but I didn’t want my host machine to become its playground.
My Bubblewrap-based setup worked well for restricting access. However, development often involves installing packages, trying different SDKs, changing configuration, and starting services. I wanted the agent to handle those tasks in an environment it could freely modify and, when necessary, rebuild.
That became oc-box: a small launcher that runs unmodified OpenCode inside a persistent, rootless Podman container.
A complete development environment
The idea is straightforward: give each project its own Linux environment.
OpenCode runs inside the container alongside its MCP servers, formatters, language servers, plugins, and development tools. Shell commands and file operations use their normal implementations—there is no OpenCode fork or replacement tool layer.
The agent can install compilers, SDKs, databases, and other dependencies inside the container without installing them on the host.
You can also choose the distribution: openSUSE Tumbleweed, Leap, Ubuntu, Debian, Fedora, Arch, or Alpine. On my Tumbleweed machine, Tumbleweed is the default.
Start in a folder, come back later
After installing oc-box, starting an environment looks like this:
mkdir -p ~/devel/demo
oc-box --project ~/devel/demoThe project directory is mounted writable at the same path inside the container. A separate, private volume provides the container’s home directory, including OpenCode’s live session database and dependency caches.
When I exit OpenCode, oc-box synchronizes conversation archives into the normal host OpenCode database and stops the container.
The next time I run the same command, it starts the existing environment and resumes the conversation. Installed tools and unfinished work are still there.
It can also bring an existing host conversation into the container:
oc-box --project ~/devel/demo \
--import-session ses_HOST_SESSION_IDThe original host conversation remains intact.
Disposable when necessary, persistent where it matters
One of the most useful features is being able to rebuild a broken environment without throwing away the project.
oc-box reset recreates the container’s OS while preserving the project directory, private home, conversation history, and session IDs. System-installed packages need reinstalling, but source files, unfinished edits, and home-directory data remain.
There are also commands to list environments, inspect CPU/RAM/storage usage, retry history synchronization after a crash, and purge an environment when it is no longer needed.
CPU, memory, and process limits provide resource ceilings rather than reserving those resources at startup. Optional device passthrough supports workloads that need GPU or NPU access.
A useful boundary, not a magic shield
Rootless Podman gives this workflow a practical separation from the host, but containers still share the host kernel.
The mounted project is intentionally writable: an agent can damage or delete its contents. Supplied credentials and accessible network services also remain available to container processes. Extra mounts and devices extend that boundary explicitly.
For me, the benefit is having a capable, replaceable development environment—not treating a container as an absolute security guarantee.
Following mainline
oc-box installs the exact OpenCode version used on the host and keeps OpenCode itself unmodified. It is developed with AI assistance, licensed GPL-3.0-or-later, and includes a command reference, man page, and GNU Info manual.
It is still an early project, primarily exercised on openSUSE Tumbleweed. Feedback from other distributions, MCP configurations, and hardware setups would be very welcome.
Source and documentation: github.com/groopcd/oc-box
Leave a Reply