Zum Hauptinhalt springen

Documentation Index

Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt

Use this file to discover all available pages before exploring further.

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 ab:
Tool-TypBeispielNormalAccept EditsBypassAutonomous (Sandbox)
SchreibgeschütztDateilesevorgänge, grep, globNeinNeinNeinNein
FetchHTTP-AnfragenJaJaNeinNein
Bash-BefehleShell-AusführungJaJaNeinNein
Dateibearbeitungen über edit/writeDateien bearbeiten/schreibenJaNein (im Workspace)NeinJa
Im Modus „Normal“ (dem Standard) werden schreibgeschützte Vorgänge 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 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 konfiguriert wurden, bleiben unabhängig vom Berechtigungsmodus des Nutzers aktiv. Unter Vorrang 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.
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 sowie unter 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\<you>\AppData\Roaming\devin\config.json) und nicht ~/.config/devin/config.json. Weitere Informationen finden Sie unter Konfigurationsdatei.
// .devin/config.json
{
  "permissions": {
    "allow": [
      "Read(src/**)",
      "Exec(npm run)"
    ],
    "deny": [
      "Exec(rm)"
    ]
  }
}

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

Read(glob)

Umfasst den Lesezugriff auf Dateien. Das Glob-Muster gleicht Dateipfade ab.
"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.
"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.
"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.
"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. 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:
{
  "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:
{
  "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
    ]
  }
}
MusterEntspricht
mcp__server__toolEin 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:
MusterBedeutung
*Beliebige Zeichen in einem einzelnen Pfadsegment
**Beliebige Zeichen über mehrere Pfadsegmente hinweg (rekursiv)
~Erweiterung zum Home-Verzeichnis
Beispiele:
"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:
OptionSpeicherortMit dem Team geteilt?
Einmal erlaubenNicht gespeichertNein
Für diese Sitzung erlaubenNur im SpeicherNein
Für dieses Projekt erlauben.devin/config.jsonJa
Für dieses Projekt erlauben (lokal).devin/config.local.jsonNein
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:
OptionWirkung
Dieses Tool zulassen (diese Sitzung)Gewährt Zugriff auf das jeweilige Tool für die aktuelle Sitzung
Dieses Tool immer zulassenSpeichert 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 zulassenSpeichert 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:
{
  "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:
{
  "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:
{
  "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(**).