OpenCode Berechtigungen: 7 sichere Entscheidungen vor Auto-Freigaben

Die sichere Grundhaltung lautet: am Anfang fragen, nur enge wiederholbare Aktionen erlauben und riskante Pfade oder Befehle verweigern. Die OpenCode-Dokumentation unterscheidet allow, ask und deny. --auto genehmigt Anfragen, die nicht ausdrücklich verweigert sind. Deshalb ist --auto Komfort, keine vollständige Sicherheitsrichtlinie.

Die Suchintention dreht sich um weniger Prompts, dauerhaftes Erlauben und gefährliches Überspringen von Berechtigungen.

Diese Anleitung hält lokale Repositorys, VS Code, Ollama, Agents, MCP und CI-nahe Aufgaben getrennt, damit gefährliche Aktionen sichtbar bleiben.

OpenCode permissions entscheiden zwischen erlauben, fragen und blockieren. Bleibe bei ask, wenn der Zweck unklar ist, nutze allow nur für enge getestete Aufgaben und deny für Löschen, Deployment, Secrets und externe Pfade. Nicht jeder Prompt ist Lärm; manche markieren eine echte Grenze.

Lesen und Suchen ist meist niedriges Risiko. Kleine Dokumentationsänderungen können nach Tests erlaubt werden. Installationen, Lockfiles, Löschen, Publishing, Migrationen und Produktion bleiben ask oder deny. Der Repository-Kontext zählt genauso wie das Tool.

`opencode --auto` genehmigt alles, was nicht verweigert ist. Vorher sollten destruktive Muster, Umgebungsdateien, Schlüsselpfade, Deployments und externe Verzeichnisse blockiert sein. Ein globaler Bypass ist keine belastbare Lösung.

Repository-Regeln gehören ins Projekt. Persönliche Vorlieben können global sein. Agent-Ausnahmen gehören zur Agent-Definition. Secrets gehören nie in `opencode.json`; dort steht Richtlinie, nicht Zugang.

Ein Review-Agent braucht viel Lesen und kein Schreiben. Ein Migrations-Agent darf vielleicht einen Ordner bearbeiten, aber nicht deployen. MCP-Tools können externe Daten ändern. Prüfe die Quelle jeder Anfrage.

Teste allow, ask und deny mit kleinem Code, generiertem Ordner, `.env.example` und harmlosem Befehl. Wenn die Regel zu breit ist, enger fassen.

Notiere Tool, Befehl, Pfad und Agent. Prüfe Working Directory, externe Pfade, MCP, Hooks, Wrapper und Config. Erweitere nicht global, wenn ein kleines Muster falsch ist.

Bevor eine OpenCode-Berechtigung in die Projektkonfiguration wandert, sollte sie an zwei Aufgaben getestet werden: eine Aufgabe, die ohne Nachfrage laufen darf, und eine Aufgabe, die sichtbar bleiben muss. Eine knappe Review beantwortet: welches Tool betroffen ist, welche Pfade oder Befehle eng begrenzt sind, welche Aktionen weiter ask oder deny bleiben und wie die Regel schnell entfernt wird. Gerade bei `opencode --auto` ist diese Grenze wichtig, weil alle nicht ausdruecklich verweigerten Anfragen automatisch genehmigt werden koennen.

Bewerte nicht nur das Tool, sondern auch den Kontext. Ein bash-Befehl fuer `npm test` ist anders zu behandeln als ein Befehl fuer Deployment, Migration, Paketinstallation oder Loeschen. Eine Dokumentationsaenderung hat ein anderes Risiko als eine Aenderung an Authentifizierung, Abrechnung, Infrastruktur oder Produktionskonfiguration. Darum sollte die Richtlinie breite Lesevorgaenge erlauben, kleine wiederholbare Edits zuerst pruefen und erst spaeter eng erlauben, gefaehrliche Kommandos aber ausdruecklich blockieren.

Wenn eine wiederholte Abfrage trotz `allow once` erneut erscheint, ist das meistens kein Grund fuer eine globale Freigabe. Notiere den genauen Befehl, das Arbeitsverzeichnis, den Pfad, die Agent-Rolle und den ausloesenden Hook oder MCP-Server. Danach kann die Regel enger angepasst werden. Fuege zur Regel eine kurze Aenderungsnotiz hinzu: Grund, erlaubtes Beispiel, blockiertes Beispiel, Datum der Pruefung und offizieller Dokumentationslink.

In der Praxis lohnt sich ausserdem ein kurzer Monatscheck. Entferne Regeln fuer Tools, die nicht mehr genutzt werden, vergleiche erlaubte Befehle mit der aktuellen Paketstruktur und pruefe, ob neue Agents oder MCP-Server mehr Rechte erhalten haben als ihr Zweck verlangt. Wenn ein Workflow nur selten laeuft, ist ask meist besser als allow, weil die kurze Rueckfrage weniger kostet als ein schwer nachvollziehbarer Seiteneffekt.

Dokumentiere besonders Ausnahmen fuer Windows, WSL, macOS und CI-nahe Aufgaben getrennt. Ein Befehl, der lokal harmlos wirkt, kann in einem anderen Arbeitsverzeichnis andere Dateien treffen. Diese Trennung macht die OpenCode permissions policy nachvollziehbar, ohne die taegliche Arbeit kuenstlich zu bremsen.

Bei Unsicherheit bleibt die engere Einstellung die bessere Wahl. Ein einzelner zusaetzlicher Prompt ist leichter zu erklaeren als ein automatischer Schreibzugriff, der erst in der Git-Diff- oder Deployment-Pruefung auffaellt. Das gilt besonders fuer neue Teammitglieder und externe Beitraege. Eine kurze Teamregel verhindert spaetere Missverstaendnisse.