Bis vor kurzem waren für mich die Web-Interfaces von OpenAI und Co. der sinnvollste Weg beim Coden. Nicht, weil sie technisch überlegen wären, sondern weil sie eine strikte Trennung erzwingen: Die KI sieht nur, was ich bewusst in den Prompt packe.

Das hat zwei Vorteile:

• Der Workspace bleibt isoliert.
• Die Code-Übernahme ist bewusst und bleibt im Flow.

Dann nutzt man einmal einen echten KI-Agenten – und versteht sofort, warum das so viele Teams begeistert.

OpenCode arbeitet nicht nur als Chatfenster, sondern als Coding-Agent mit Werkzeugen: Er liest Dateien, schreibt Änderungen, nutzt installierte CLI-Tools und kann Builds oder Tests validieren. Alles lokal, direkt am Workspace und damit viel näher am realen Entwicklungsablauf.

Wo das Risiko beginnt

Die Installation wirkt trivial: npm install, starten, loslegen. Klingt harmlos – ist es aber nicht automatisch.

Wenn ein Agent ohne Isolation läuft, hat er im Zweifel Zugriff auf den gesamten Kontext des Users: Home-Verzeichnis, Konfig-Dateien, Schlüsselmaterial, Mails, Dokumente und vieles mehr.

OpenCode fragt beim Verlassen des Start-Workspaces zwar ordentlich nach, ob es eine Ebene höher schauen darf. Das ist gut – aber es bleibt eine Verhaltensgrenze, keine harte technische Grenze.

Was OpenCode eigentlich ist (und wie es arbeitet)

OpenCode ist ein CLI-basierter KI-Coding-Agent. Das bedeutet:

1. Aufgaben werden analysiert und in Arbeitsschritte zerlegt.
2. Für jeden Schritt werden passende Tools verwendet (Dateien, Shell, Git, Suche).
3. Ergebnisse werden geprüft und bei Bedarf iterativ verbessert.

Der Unterschied zur klassischen „Prompt → Code-Snippet → Copy/Paste“-Nutzung ist enorm: Agenten können den Kontext der Codebasis direkt verarbeiten und Arbeitsschleifen automatisieren.

Das ist produktiv – aber genau deshalb muss die Umgebung sauber begrenzt sein.

Der pragmatische Weg: OpenCode mit Podman sandboxen

Mein Setup ist bewusst einfach:

• OpenCode läuft im Container.
• Konfiguration/Cache liegen in einem persistenten Volume.
• Gemountet wird nur der explizit gestartete Workspace.
• Kein pauschaler Zugriff auf das echte Host-$HOME.

Damit bleibt der Agent nützlich, aber der Scope ist deutlich enger.

Setup-Dateien

Die folgenden Dateien nutze ich genau so.

1) Containerfile

FROM docker.io/library/node:22-trixie

RUN apt-get update \
 && apt-get install -y --no-install-recommends \
    # core
    git ripgrep fd-find curl jq bash ca-certificates \
    # c
    build-essential gdb pkg-config strace ltrace \
    # python
    python3 python3-pip python3-venv \
    # go
    golang \
 && rm -rf /var/lib/apt/lists/*

# fd alias (Debian quirk)
RUN ln -s /usr/bin/fdfind /usr/local/bin/fd

# opencode installieren
RUN npm install -g opencode-ai \
 && test -f /usr/local/lib/node_modules/opencode-ai/bin/.opencode

USER node

WORKDIR /workspace
ENV HOME=/home/node

ENTRYPOINT ["opencode"]

Warum sinnvoll?

• Enthält OpenCode plus typische Dev-Toolchain.
• Läuft als node statt root.
• Setzt klaren Arbeitskontext auf /workspace.

2) Makefile

IMAGE_NAME ?= opencode
IMAGE_TAG  ?= latest
IMAGE      := $(IMAGE_NAME):$(IMAGE_TAG)

CONTAINERFILE ?= Containerfile

.PHONY: all build rebuild clean run shell

all: build

build:
	podman build \
		-t $(IMAGE) \
		-f $(CONTAINERFILE) \
		.

rebuild:
	podman build \
		--no-cache \
		-t $(IMAGE) \
		-f $(CONTAINERFILE) \
		.

clean:
	podman image rm -f $(IMAGE) || true

run:
	podman run --rm -it \
		--userns=keep-id \
		--cap-drop=ALL \
		--security-opt=no-new-privileges \
		-v $$(pwd):/workspace:Z \
		$(IMAGE)

shell:
	podman run --rm -it \
		--entrypoint /bin/sh \
		--userns=keep-id \
		-v $$(pwd):/workspace:Z \
		$(IMAGE)

3) Wrapper-Skript opencode

#!/bin/sh
set -eu

IMAGE="${OPENCODE_IMAGE:-opencode:latest}"
VOLUME="${OPENCODE_VOLUME:-opencode-data}"

exec podman run --rm -it --userns=keep-id --cap-drop=ALL -v "$(pwd):/workspace" -v "${VOLUME}:/home/node" --tmpfs /home/node/.local/share/opencode/snapshot -w /workspace "$IMAGE" "$@"

Das Skript kapselt die wichtigen Defaults:

• Workspace-Mount nur für den aktuellen Pfad
• Persistentes Volume für /home/node (Konfig/Cache)
• Reduzierte Container-Rechte durch --cap-drop=ALL
• Container wird nach Nutzung entfernt (--rm)

So nutzt du das Setup

1. Dateien in ein Verzeichnis legen (Containerfile, Makefile, opencode).
2. Image bauen: make build
3. Wrapper ausführbar machen: chmod +x opencode
4. Im gewünschten Projekt starten: ./opencode

Optional:

• anderes Image: OPENCODE_IMAGE=my-opencode:dev ./opencode
• eigenes Volume je Projekt: OPENCODE_VOLUME=opencode-projekt-a ./opencode

Warum das sicherer ist – und wo die Grenzen liegen

Sicherer, weil:

• der Agent nur den gemounteten Workspace sieht,
• Konfig-Daten isoliert im Volume liegen,
• Host-Home standardmäßig draußen bleibt,
• Laufzeitrechte bewusst eingeschränkt werden.

Nicht perfekt, weil:

• alles im gemounteten Workspace weiterhin sichtbar ist,
• Netzwerkzugriff ohne zusätzliche Flags möglich bleibt,
• Supply-Chain-Themen (Base-Image, npm-Paket) trotzdem relevant sind.

Fazit

OpenCode ist als KI-Coding-Agent extrem effizient, weil es den Engineering-Workflow integriert statt nur Snippets zu liefern.

Genau deshalb sollte man den Betrieb nicht „mal eben“ auf dem Host freischalten. Mit Podman, klarem Workspace-Mount und persistentem Konfig-Volume bekommt man einen pragmatischen Sweet Spot: hohe Produktivität bei deutlich besserer Kontrolle über den Kontext.

Oder kurz: Nicht weniger KI – sondern bessere Laufzeitgrenzen.