Ein Coding Agent ist schnell. Er liest Dateien, schreibt Code und startet Befehle im Terminal. Genau deshalb braucht er Grenzen. Mit den OpenCode Permissions legt ihr fest, was der Agent einfach tun darf, wo er fragen muss und was komplett tabu ist. Wir arbeiten täglich mit OpenCode. Hier steht, wie wir die Rechte einstellen und warum.
NCA KI Workshop für Developer: Euer Team lernt Agentic Coding für die Produktion, mit Regeln, Rechten und Quality Gates, die im Alltag wirklich greifen. Zum KI Workshop für Developer
Warum ein Coding Agent klare Grenzen braucht
Ohne eigene Einstellungen ist OpenCode sehr großzügig. Die meisten Aktionen sind erlaubt. Das ist bequem, solange alles gut läuft. Kritisch wird es bei Befehlen, die sich nicht zurückholen lassen. Ein git push auf den falschen Branch. Ein rm im falschen Ordner. Ein Agent, der in einer Schleife immer wieder denselben Befehl startet.
Permissions sind die erste Leitplanke. Sie wirken, bevor etwas passiert. Tests und Reviews greifen erst danach. Beides gehört zusammen. Warum Leitplanken mit jedem besseren Modell wichtiger werden, steht im Beitrag KI Guardrails und bessere Modelle.
Die drei Werte allow, ask und deny
Jede Regel in OpenCode endet bei einem von drei Werten:
- allow: Der Agent darf die Aktion ohne Rückfrage ausführen.
- ask: OpenCode fragt euch vorher um Erlaubnis.
- deny: Die Aktion ist gesperrt.
Ohne eigene Konfiguration gelten die Standardwerte. Die meisten Rechte stehen auf allow. Zwei Schutzregeln fragen nach: doom_loop und external_directory. Und .env Dateien darf der Agent nicht lesen, nur .env.example ist erlaubt.
Eine sichere Grundkonfiguration für den Alltag
Die Rechte stehen in der opencode.json im Projekt. So sieht eine Grundkonfiguration aus, mit der man gut arbeiten kann:
{
"$schema": "https://opencode.ai/config.json",
"permission": {
"bash": {
"*": "ask",
"npm run *": "allow",
"npm test*": "allow",
"git status*": "allow",
"git diff*": "allow",
"git log*": "allow",
"git push *": "deny",
"rm *": "deny"
},
"webfetch": "ask"
}
}Build, Tests und lesende Git Befehle laufen ohne Rückfrage. Alles andere im Terminal fragt nach. Push und Löschen sind gesperrt. Den Push macht ihr selbst, nachdem ihr den Diff gelesen habt. Das kostet ein paar Sekunden und spart im Ernstfall Stunden.
Wie OpenCode die Regeln auswertet
Bei mehreren Regeln für ein Werkzeug gewinnt die letzte passende Regel. Deshalb steht die allgemeine Regel mit * immer oben. Die speziellen Regeln folgen darunter. Für die Muster gibt es zwei Platzhalter:
*passt auf beliebig viele Zeichen, auch auf keins.?passt auf genau ein Zeichen.
Ein häufiger Stolperstein: "git status" greift nur ohne Argumente. Mit "git status*" erfasst ihr auch git status --short. Prüft eure Muster deshalb immer mit den Befehlen, die der Agent wirklich nutzt.
Rechte pro Agent vergeben
Ihr könnt Rechte für einzelne Agents überschreiben. Die Regeln des Agents haben dann Vorrang vor den globalen Regeln. So darf der Build Agent mehr als ein Review Agent:
{
"$schema": "https://opencode.ai/config.json",
"agent": {
"build": {
"permission": {
"bash": {
"*": "ask",
"git *": "allow",
"git commit *": "ask",
"git push *": "deny"
}
}
}
}
}Einen eigenen Review Agent legt ihr als Markdown Datei an, zum Beispiel unter ~/.config/opencode/agents/review.md. Im Frontmatter steht, dass er nichts ändern darf:
---
description: Code Review ohne Änderungen
mode: subagent
permission:
edit: deny
bash: ask
webfetch: deny
---
Analysiere den Code und schlage Änderungen vor. Ändere selbst nichts.Was once, always und reject bedeuten
Steht eine Regel auf ask, zeigt OpenCode drei Antworten. Mit once erlaubt ihr genau diese eine Aktion. Mit always erlaubt ihr alle ähnlichen Aktionen für den Rest der Session, zum Beispiel alle Befehle, die mit git status beginnen. Mit reject lehnt ihr ab. Always gilt nur für die laufende Session. Was ihr dauerhaft erlauben wollt, gehört in die opencode.json.
Doom Loop und fremde Ordner absichern
Zwei Regeln schützen vor typischen Agent Fehlern. doom_loop greift, wenn der Agent dieselbe Aktion dreimal mit identischer Eingabe wiederholt. Das ist fast immer ein Zeichen, dass er feststeckt. Lasst diese Regel auf ask.
external_directory greift, wenn der Agent Pfade außerhalb des Projekts anfasst. Braucht ihr einen zweiten Ordner, gebt genau diesen frei. Wollt ihr dort nur lesen, sperrt ihr edit für denselben Pfad:
{
"$schema": "https://opencode.ai/config.json",
"permission": {
"external_directory": {
"~/projects/shared/**": "allow"
},
"edit": {
"~/projects/shared/**": "deny"
}
}
}Wann der Auto Modus passt
Mit opencode --auto bestätigt OpenCode alle Anfragen selbst, die sonst nachfragen würden. Regeln mit deny bleiben aktiv. Das ist praktisch für Wegwerf Experimente in einem frischen Ordner. Für echte Projekte mit Kundencode nutzen wir den Auto Modus nicht. Dort soll ein Mensch sehen, was passiert. Im TUI schaltet ihr den Modus über die Befehlspalette ein und wieder aus.
Alle wichtigen Permissions im Überblick
| Permission | Wofür | Unsere Empfehlung |
|---|---|---|
| bash | Befehle im Terminal | ask als Standard, Build und Tests auf allow, Push und Löschen auf deny |
| edit | Dateien ändern und anlegen | allow im Projekt, deny in geteilten Ordnern |
| read | Dateien lesen | allow, .env bleibt gesperrt |
| webfetch | Webseiten abrufen | ask oder Freigabe für bekannte Doku Seiten |
| task | Subagents starten | allow für bekannte Agents |
| external_directory | Pfade außerhalb des Projekts | ask, nur gezielte Ordner freigeben |
| doom_loop | Dreimal dieselbe Aktion | ask |
Die vollständige Liste steht in der OpenCode Doku zu Permissions. Wie Agents sich unterscheiden, erklärt die OpenCode Doku zu Agents. Den Quellcode und aktuelle Releases findet ihr im OpenCode Repository auf GitHub.
Wie wir Teams beim Einrichten von OpenCode helfen
OpenCode ist bei uns der Coding Agent im Alltag, mit Open Weight Modellen aus den Familien GLM und Qwen. Gute Rechte sind nur ein Teil. Dazu kommen Regeln in der AGENTS.md, Quality Gates in der Pipeline und Tests mit Cypress. Den Überblick über Astro, GitHub Pages und OpenCode findet ihr in unseren Vibe Coding Tipps und Tricks. Wie ihr feste Abläufe baut, zeigt OpenCode Commands erstellen, und den Agent in GitHub erklärt OpenCode GitHub Action einrichten. Welche Modelle sich eignen, vergleichen wir bei den Vibe Coding Modellen.
Begleitung im Projekt gibt es in der Vibe Coding Beratung. Pipelines für KI Code beschreiben wir bei den Vibe Coding CI/CD Pipelines. Wer Git Kontext direkt im Agent will, schaut sich den GitKraken MCP Server für OpenCode an. Und warum Tests die zweite Leitplanke sind, steht in End to End Tests für jedes Webprojekt. Das Vorgespräch ist kostenlos, abgerechnet wird transparent nach Minuten.
Häufige Fragen zu OpenCode Permissions
Was darf OpenCode 2026 ohne eigene Permissions?
Ohne eigene Konfiguration stehen die meisten Rechte auf allow. Der Agent darf also lesen, schreiben und Befehle starten. Nur doom_loop und external_directory fragen nach, und .env Dateien sind beim Lesen gesperrt. Für echte Projekte solltet ihr die Rechte deshalb selbst festlegen.
Wo stehen die OpenCode Permissions 2026?
Die Rechte stehen im Feld permission der opencode.json. Die Datei liegt im Projekt oder global unter ~/.config/opencode. Rechte für einzelne Agents setzt ihr im Feld agent oder im Frontmatter einer Agent Datei in Markdown. Die Regeln eines Agents haben Vorrang vor den globalen Regeln.
Welche Regel gewinnt bei OpenCode 2026?
Bei mehreren passenden Regeln gewinnt immer die letzte. Schreibt deshalb die allgemeine Regel mit Sternchen zuerst und die speziellen Regeln danach. So steht zum Beispiel bash auf ask, npm run auf allow und git push auf deny, und jede Regel greift genau dort, wo sie soll.
Ist der Auto Modus von OpenCode 2026 sicher?
Der Auto Modus bestätigt alle Anfragen selbst, die sonst nachfragen würden. Regeln mit deny bleiben aktiv. Für Experimente in einem leeren Ordner ist das praktisch. Für Projekte mit Kundencode empfehlen wir ihn nicht, dort soll ein Mensch jede kritische Aktion sehen.
Kann OpenCode meine .env Datei lesen?
Standardmäßig nein. OpenCode sperrt das Lesen von .env und .env Varianten. Nur .env.example ist erlaubt. Lasst diese Regel so stehen. Secrets gehören weder in den Kontext eines Modells noch in einen Prompt. Für lokale Entwicklung arbeitet ihr am besten mit Testdaten statt echter Zugangsdaten.
Was ist der Doom Loop in OpenCode?
Der Doom Loop ist eine Schutzregel. Sie greift, wenn der Agent dieselbe Aktion dreimal mit identischer Eingabe wiederholt. Dann steckt er meist fest. Mit ask fragt OpenCode euch, bevor es weitergeht. So brecht ihr Schleifen früh ab und gebt dem Agent einen besseren Hinweis.
OpenCode mit sicheren Rechten für euer Team
Wir richten OpenCode mit Permissions, Regeln und Quality Gates für euer Team ein, oder eure Developer lernen es im KI Workshop selbst. Das Vorgespräch ist kostenlos, abgerechnet wird transparent nach Minuten.
