> ## Documentation Index > Fetch the complete documentation index at: https://docs.devin.ai/llms.txt > Use this file to discover all available pages before exploring further. # Berechtigungen > Legen Sie mit detaillierten Berechtigungsregeln fest, was der Agent tun darf Das Berechtigungssystem legt fest, welche Aktionen der Agent ohne Ihre Zustimmung ausführen darf. Sie können sichere Aktionen vorab genehmigen, gefährliche blockieren und bei sensiblen Vorgängen stets eine Bestätigung verlangen. ***
## Standardverhalten für Berechtigungen
Devin CLI verwendet ein abgestuftes Berechtigungssystem, um Funktionsumfang und Sicherheit auszubalancieren. Das Standardverhalten hängt vom aktuellen [Modus](/de/cli/essential-commands#modes) ab: Jede Zelle zeigt, ob das Tool in diesem Modus automatisch ausgeführt wird (**Auto**, ohne Rückfrage) oder auf Ihre Bestätigung wartet (**Bestätigung**): | Tool-Typ | Beispiel | Normal | Accept Edits | Bypass | Autonomous (Sandbox) | | -------------------------------------- | ----------------------------- | ----------- | ------------------- | ------ | -------------------- | | Schreibgeschützt | Dateilesevorgänge, grep, glob | Auto | Auto | Auto | Auto | | Fetch | HTTP-Anfragen | Bestätigung | Bestätigung | Auto | Auto | | Bash-Befehle | Shell-Ausführung | Bestätigung | Bestätigung | Auto | Auto | | Dateibearbeitungen über `edit`/`write` | Dateien bearbeiten/schreiben | Bestätigung | Auto (im Workspace) | Auto | Bestätigung | Im **Modus „Normal“** (dem Standard) wird schreibgeschützter Zugriff automatisch genehmigt, während Schreibvorgänge und Shell-Befehle Ihre ausdrückliche Zustimmung erfordern. Jedes Mal, wenn Sie eine Aktion genehmigen, können Sie festlegen, ob sie einmalig, für die Sitzung oder dauerhaft für das Projekt erlaubt werden soll. Im **Modus „Accept Edits“** werden Dateibearbeitungen innerhalb des Workspace automatisch genehmigt, aber Shell-Befehle und Schreibvorgänge außerhalb des Workspace erfordern weiterhin eine Bestätigung. Im **Modus „Bypass“** werden alle Tool-Aufrufe automatisch genehmigt, ohne Rückfrage. Im **Autonomous-Modus** werden Shell-Befehle und Netzwerkabrufe automatisch genehmigt, da die Sandbox auf Betriebssystemebene durchsetzt, worauf sie zugreifen dürfen. Direkte Dateibearbeitungen über die Tools `edit`/`write` erfordern weiterhin eine Bestätigung, da diese Tools außerhalb der Sandbox arbeiten. Der Autonomous-Modus ist nur verfügbar, wenn die [Sandbox auf Betriebssystemebene](#autonomous-mode) aktiv ist. Die Modi Bypass und Autonomous **setzen Berechtigungen auf Organisationsebene nicht außer Kraft**. Von Admins erzwungene Regeln zum Verweigern und Nachfragen, die über [Team Settings](/de/cli/enterprise/team-settings) konfiguriert wurden, bleiben unabhängig vom Berechtigungsmodus des Nutzers aktiv. Unter [Vorrang](#precedence) finden Sie weitere Details.
### Autonomous-Modus
Autonomous ist der Berechtigungsmodus, der mit dem Flag `--sandbox` verwendet wird. Konzeptionell entspricht er ungefähr „Accept Edits im aktuellen Workspace“ plus der Möglichkeit, beliebige Shell-Befehle auszuführen, wobei beide Verhaltensweisen durch die Sandbox auf Betriebssystemebene begrenzt sind. Wenn die Sandbox aktiv ist: * **Dies ist der einzige verfügbare Berechtigungsmodus.** Normal, Accept Edits und Bypass sind in Sandbox-Sitzungen ausgeblendet. Der Plan-Modus bleibt verfügbar. * **Shell-Befehle und Fetches werden automatisch genehmigt** statt nachzufragen, da die Sandbox durchsetzt, was sie lesen, schreiben und über das Netzwerk erreichen dürfen. * **Direkte Dateibearbeitungen über die Tools `edit` und `write` erfordern weiterhin eine Bestätigung.** Diese Tools laufen im CLI-Prozess und nicht innerhalb der Sandbox und können daher nicht durch sie begrenzt werden. Wird an der Eingabeaufforderung ein Geltungsbereich `Write(...)` gewährt, erweitert das die Sandbox dynamisch, sodass nachfolgende Shell-Befehle dort schreiben können. * **Während der Sitzung gewährte Geltungsbereiche erweitern die Sandbox dynamisch** für nachfolgende Befehle. ```bash theme={null} devin --sandbox --permission-mode autonomous ``` Verwende Bypass, wenn du eine uneingeschränkte Ausführung ohne Isolierung auf Betriebssystemebene möchtest; verwende `--sandbox` (wodurch Autonomous ausgewählt wird), wenn du eine unbeaufsichtigte Ausführung mit vom Betriebssystem erzwungenen Einschränkungen beim Zugriff auf Dateisystem und Netzwerk möchtest. Details zu schreib- und lesbaren Stammverzeichnissen und zur Domain-Filterung findest du in der [Referenz zur Sandbox-Konfiguration](/de/cli/reference/configuration/config-file#sandbox) sowie unter [Team Settings → Sandbox Enforcement](/de/cli/enterprise/team-settings#sandbox-enforcement) für Enterprise-weite Steuerungsoptionen. ***
## So funktionieren Berechtigungen
Wenn der Agent ein Tool aufruft, prüft das Berechtigungssystem Ihre Regeln in dieser Prioritätsreihenfolge: 1. **Ablehnungsregeln** — Werden zuerst geprüft. Bei einer Übereinstimmung wird die Aktion sofort blockiert. 2. **Rückfrageregeln** — Werden als Zweites geprüft. Bei einer Übereinstimmung werden Sie immer um Bestätigung gebeten (überschreibt alle Erlaubnisregeln). 3. **Erlaubnisregeln** — Werden zuletzt geprüft. Bei einer Übereinstimmung wird die Aktion ohne Rückfrage ausgeführt. 4. **Standard** — Wenn keine Regel übereinstimmt, werden Sie um Freigabe gebeten. Da Ablehnungsregeln vor Rückfrageregeln und Rückfrageregeln vor Erlaubnisregeln geprüft werden, hat eine Ablehnungsregel immer Vorrang. Wenn derselbe Geltungsbereich sowohl auf eine Ablehnungsregel als auch auf eine Rückfrageregel zutrifft, gilt die Ablehnungsregel. ***
## Konfiguration
Fügen Sie dem Abschnitt `permissions` in Ihrer Konfigurationsdatei Berechtigungen hinzu: Unter Windows lautet der Pfad zur Nutzerkonfiguration `%APPDATA%\devin\config.json` (in der Regel `C:\Users\\AppData\Roaming\devin\config.json`) und nicht `~/.config/devin/config.json`. Weitere Informationen finden Sie unter [Konfigurationsdatei](/de/cli/reference/configuration/config-file#file-locations). ```json theme={null} // .devin/config.json { "permissions": { "allow": [ "Read(src/**)", "Exec(npm run)" ], "deny": [ "Exec(rm)" ] } } ``` ```json theme={null} // ~/.config/devin/config.json { "permissions": { "allow": [ "Read(**)", "Exec(git)" ] } } ``` ```json theme={null} // .devin/config.local.json { "permissions": { "allow": [ "Exec(docker compose)" ] } } ``` ***
## Syntax für Berechtigungen
Es gibt zwei Arten von Berechtigungs-Matchern: **geltungsbereichsbasiert** (steuert, auf welche Pfade/Befehle/URLs zugegriffen werden kann) und **toolbasiert** (steuert, welche Tools verwendet werden können).
### Geltungsbereichsbasierte Berechtigungen
Umfasst den Lesezugriff auf Dateien. Das Glob-Muster gleicht Dateipfade ab. ```json theme={null} "allow": [ "Read(src/**)", // Alle Dateien unter src/ "Read(~/.config/**)", // Konfigurationsdateien im Home-Verzeichnis "Read(/tmp/**)" // Temporäres Verzeichnis ] ``` Verzeichnispfade gleichen automatisch alle darin enthaltenen Dateien ab. Umfasst den Schreib- und Bearbeitungszugriff auf Dateien. ```json theme={null} "allow": [ "Write(src/**)", // Kann überall in src/ schreiben "Write(tests/**)" // Kann Testdateien schreiben ], "deny": [ "Write(*.lock)", // Kann Lock-Dateien nicht ändern "Write(.env*)" // Kann .env-Dateien nicht ändern ] ``` Umfasst die Ausführung von Shell-Befehlen. Gleicht Befehle ab, die mit dem angegebenen Präfix beginnen. ```json theme={null} "allow": [ "Exec(git)", // git, git status, git commit... "Exec(npm run)", // npm run test, npm run build... "Exec(python)" // python, python script.py... ], "deny": [ "Exec(rm)", // Blockiert rm, rm -rf usw. "Exec(sudo)" // Blockiert sudo-Befehle ] ``` `Exec(git)` gleicht „git“, „git status“ und „git commit -m 'msg'“ ab, aber NICHT „gitk“ oder „github-cli“. Das Präfix muss als vollständiges Wort übereinstimmen. Umfasst den HTTP-Fetch-Zugriff mithilfe von URL-Mustern. ```json theme={null} "allow": [ "Fetch(https://api.github.com/*)", // GitHub-API "Fetch(https://*.example.com/*)", // Alle Subdomains von example.com "Fetch(domain:npmjs.org)" // Beliebige URL auf npmjs.org ] ``` URL-Muster folgen dem Standard [WHATWG URL Pattern](https://urlpattern.spec.whatwg.org/). Die Kurzform `domain:` gleicht jeden Pfad auf der exakten Domain ab.
### Toolbasierte Berechtigungen
Anhand des Tool-Namens abgleichen, um den Zugriff auf ganze Tools zu steuern: ```json theme={null} { "permissions": { "deny": [ "edit", // Alle Dateibearbeitungen blockieren "exec" // Alle Befehlsausführungen blockieren ], "allow": [ "read", // Alle Dateilesevorgänge erlauben "grep", // Alle Suchen erlauben "glob" // Alle Dateisuchen erlauben ] } } ``` **Verfügbare Tool-Namen:** `read`, `edit`, `grep`, `glob`, `exec`
### Berechtigungen für MCP-Tools
Steuern Sie den Zugriff auf Tools des MCP-Servers: ```json theme={null} { "permissions": { "allow": [ "mcp__github__list_issues", // Bestimmtes Tool auf bestimmtem Server "mcp__github__*", // Alle Tools auf dem GitHub-Server "mcp__*" // Alle MCP-Tools ], "deny": [ "mcp__github__delete_repo" // Bestimmtes gefährliches Tool blockieren ] } } ``` | Muster | Entspricht | | ------------------- | --------------------------- | | `mcp__server__tool` | Ein bestimmtes Tool | | `mcp__server__*` | Alle Tools auf einem Server | | `mcp__*` | Alle MCP-Tools überall | ***
## Pfadmuster
In `Read()` und `Write()` werden folgende Glob-Muster unterstützt: | Muster | Bedeutung | | ------ | ------------------------------------------------------------- | | `*` | Beliebige Zeichen in einem einzelnen Pfadsegment | | `**` | Beliebige Zeichen über mehrere Pfadsegmente hinweg (rekursiv) | | `~` | Erweiterung zum Home-Verzeichnis | **Beispiele:** ```json theme={null} "allow": [ "Read(**)", // Alle Dateien überall "Read(src/**/*.ts)", // Alle TypeScript-Dateien in src/ "Write(~/projects/myapp/**)" // In bestimmtes Projekt schreiben ] ``` Verwenden Sie ein absolutes Pfadpräfix (z. B. `Read(/**)`), wenn Sie alle Dateien auf dem System erfassen möchten. Ein einfaches `Read(**)` ohne führendes `/` wird relativ zu Ihrem aktuellen Arbeitsverzeichnis aufgelöst und erfasst daher nur Dateien in diesem Verzeichnis — nicht Dateien, auf die an anderer Stelle über absolute Pfade zugegriffen wird. ***
## Persistenzoptionen
Wenn der Agent während einer Sitzung um Erlaubnis bittet, können Sie festlegen, wie Ihre Entscheidung gespeichert werden soll: | Option | Speicherort | Mit dem Team geteilt? | | ----------------------------------- | --------------------------------------------------------------------------- | --------------------- | | Einmal erlauben | Nicht gespeichert | Nein | | Für diese Sitzung erlauben | Nur im Speicher | Nein | | Für dieses Projekt erlauben | `.devin/config.json` | Ja | | Für dieses Projekt erlauben (lokal) | `.devin/config.local.json` | Nein | | Global erlauben | `~/.config/devin/config.json` (`%APPDATA%\devin\config.json` unter Windows) | Nein |
### Berechtigungen auf MCP-Server-Ebene
Wenn Sie zur Verwendung eines bestimmten MCP-Tools aufgefordert werden (z. B. `list_issues` auf dem Figma-Server), bietet die Berechtigungsabfrage auch umfassendere Optionen auf Server-Ebene: | Option | Wirkung | | ----------------------------------------------------- | ------------------------------------------------------------------------- | | Dieses Tool zulassen (diese Sitzung) | Gewährt Zugriff auf das jeweilige Tool für die aktuelle Sitzung | | Dieses Tool immer zulassen | Speichert die Berechtigung für dieses Tool dauerhaft in der Konfiguration | | Alle Tools auf diesem Server zulassen (diese Sitzung) | Gewährt für die aktuelle Sitzung Zugriff auf alle Tools auf dem Server | | Tools auf diesem Server immer zulassen | Speichert den serverweiten Zugriff dauerhaft in der Konfiguration | So können Sie einem vertrauenswürdigen MCP-Server schnell pauschalen Zugriff gewähren, ohne jedes Tool einzeln genehmigen zu müssen. ***
## Vorrang
Wenn mehrere Berechtigungsquellen Regeln definieren, werden sie mit folgender Priorität zusammengeführt (höchste zuerst): 1. Organisations-/Team-Settings (bei Enterprise) 2. Freigaben auf Sitzungsebene (interaktive Genehmigungen) 3. Lokale Projektkonfiguration (`.devin/config.local.json`) 4. Projektkonfiguration (`.devin/config.json`) 5. Nutzerkonfiguration (`~/.config/devin/config.json`; `%APPDATA%\devin\config.json` unter Windows) Verweigerungen auf Organisationsebene können nicht durch die Projekt- oder Nutzerkonfiguration außer Kraft gesetzt werden. So wird sichergestellt, dass Enterprise-Richtlinien durchgesetzt werden. ***
## Beispiele
### Minimales Development-Setup
Erlaube gängige schreibgeschützte Zugriffe, frage bei allem anderen nach: ```json theme={null} { "permissions": { "allow": [ "Read(**)", "Exec(git status)", "Exec(git diff)", "Exec(git log)" ] } } ```
### Volles Vertrauen für ein Projekt
Die meisten Vorgänge im Projekt automatisch genehmigen: ```json theme={null} { "permissions": { "allow": [ "Read(**)", "Write(src/**)", "Write(tests/**)", "Exec(npm)", "Exec(git)", "Exec(node)" ], "deny": [ "Exec(rm -rf)", "Exec(sudo)", "Write(.env*)" ] } } ```
### Stark abgesichertes Enterprise
Auf bestimmte sichere Operationen beschränken, bei Schreibvorgängen immer nachfragen: ```json theme={null} { "permissions": { "allow": [ "Read(src/**)", "Exec(git status)", "Exec(git diff)", "Exec(npm run lint)" ], "deny": [ "Exec(rm)", "Exec(sudo)", "Write(.env*)" ], "ask": [ "Write(**)", "exec" ] } } ``` In diesem Beispiel werden Schreibvorgänge in `.env*` grundsätzlich verweigert, alle anderen Schreibvorgänge erfordern immer eine Bestätigung durch den Nutzer, und nur wenige schreibgeschützte Befehle werden automatisch genehmigt. Da deny vor ask geprüft wird, hat die Verweigerung für `.env*` Vorrang vor der ask-Regel `Write(**)`.