OpenCode Sandbox

Run OpenCode in an isolated Docker sandbox so it can only access the current project directory.

Setup

1. Build image

./build.sh

2. Add this to your ~/.zshrc

opencode() {
  docker run -it --rm \
    -v "$PWD":/workspace \
    -w /workspace \
    opencode-sandbox \
    opencode
}

Tip

• docker run starts a new container from an image.
• -it gives you an interactive terminal.
• --rm deletes the container when you exit (no leftover containers or clutter).
• -v "$PWD":/workspace is the most important line - it mounts the folder you are in ($PWD) into the container, under /workspace. This is the sandbox boundary.
• -w /workspace starts you in this directory.
• opencode-sandbox is the image you built in step 1, that this container is based on.
• finally, opencode drops you into your OpenCode session.

3. In any project

cd ~/your-new-project && opencode 

4. To update OpenCode

./build.sh

---

Note

This is a personal project I built for myself to explore a safer CLI-based agent workflow.

I’m sharing it in case it’s useful or interesting to others experimenting in the same space.

Why this exists

I wanted a lightweight, terminal-first way to use CLI coding agents (like OpenCode) without giving them unrestricted access to my machine.

This project gives me a few things I personally care about:

• A clear boundary between my system and the agent
• Reproducible environments
• A simple CLI workflow

Tradeoffs

I intentionally stopped at a “good enough” isolation model rather than building a fully locked-down sandbox.

For example:

• The container still allows network access by default

I chose this balance because:

• I still want the tool to feel like a normal developer workflow
• Many agent capabilities rely on network access (docs, APIs, tooling)
• This is primarily for local development, not adversarial security

Limitations

This project intentionally prioritizes simplicity and generality over performance optimization.

A key limitation is that dependencies are installed inside the container at runtime. This means that:

• Dependencies must be re-installed on container startup
• It will be slower than fully cached environments

This is personally acceptable - this tool is designed for personal use and experimentation and is not intended for production environments.

In future iterations, this could be extended to support cached builds or project-specific images if startup performance becomes a bottleneck.