Berechtigungen

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: 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	Smart	Bypass	Autonomous (Sandbox)
Schreibgeschützt	Dateilesevorgänge, grep, glob	Auto	Auto	Auto	Auto	Auto
Fetch	HTTP-Anfragen	Bestätigung	Bestätigung	Auto, wenn als sicher eingestuft	Auto	Auto
Bash-Befehle	Shell-Ausführung	Bestätigung	Bestätigung	Auto, wenn als sicher eingestuft	Auto	Auto
Dateibearbeitungen über `edit`/`write`	Dateien bearbeiten/schreiben	Bestätigung	Auto (im Workspace)	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 Smart-Modus werden Bearbeitungen im Workspace wie im Modus „Accept Edits“ automatisch genehmigt, und jede andere Aktion wird von einem schnellen Modell beurteilt, das sie nur dann automatisch ausführt, wenn sie eindeutig sicher ist. Bei allen anderen Aktionen wird wie üblich nachgefragt. Weitere Informationen finden Sie unten unter Smart-Modus. Im Modus „Bypass“ werden alle Tool-Aufrufe automatisch genehmigt, ohne Rückfrage. Im Autonomous-Modus werden Shell-Befehle und Netzwerk-Fetches 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 Smart, 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.

Smart-Modus

Smart liegt zwischen Accept Edits und Bypass. Bearbeitungen von Dateien im Workspace werden genau wie bei Accept Edits automatisch genehmigt. Bei allen anderen Aktionen — Shell-Befehlen, Web-Abrufen, MCP-Tools und Schreibvorgängen außerhalb des Workspace — beurteilt ein schnelles Modell, ob die Aktion sicher unbeaufsichtigt ausgeführt werden kann. Ist sie eindeutig sicher, wird die Aktion ohne Aufforderung ausgeführt. Ist sie nicht eindeutig sicher oder das Modell unsicher oder nicht verfügbar, erhalten Sie die normale Genehmigungsaufforderung.

/smart
# oder
/mode smart

Du kannst auch mit Shift+Tab zu Smart wechseln, den Modus im Modusauswahlmenü auswählen oder direkt darin starten:

devin --permission-mode smart
# oder
DEVIN_PERMISSION_MODE=smart devin

Das Modell beurteilt nur routinemäßige Entwicklungsaufgaben – also das Erstellen, Testen, Linten, Formatieren und Untersuchen des Projekts. Einige Kategorien werden im Smart-Modus nie automatisch genehmigt, unabhängig davon, wie das Modell sie einschätzt:

Paketinstallationen (npm install, pip install, cargo install, brew install, …)
Ändernde git-Operationen (schreibgeschützte Unterbefehle wie git status kommen weiterhin infrage)
rm, sudo und andere destruktive oder berechtigungsausweitende Befehle
kubectl delete und destruktive Cloud-CLI-Operationen (aws, gcloud, az, terraform, …)
Alles, was dotenv-Dateien, Schlüsselmaterial, die Git-Konfiguration oder die eigene Konfiguration des Agenten liest oder schreibt

Smart unterscheidet sich von den benachbarten Modi darin, was automatisch ausgeführt wird:

	Accept Edits	Smart	Bypass
Bearbeitungen von Workspace-Dateien	Automatisch	Automatisch	Automatisch
Shell-Befehle und Fetch	Immer nachfragen	Nur automatisch, wenn das Modell sie als sicher einstuft	Immer automatisch
Befehle mit hohem Risiko (Installationen, `rm`, `sudo`, ändernde `git`-Operationen)	Immer nachfragen	Immer nachfragen	Immer automatisch

Ihre eigenen Regeln haben weiterhin Vorrang. Die Einschätzung von Smart gilt nur, wenn keine Regel die Entscheidung bereits vorgibt. Eine deny-Regel blockiert die Aktion daher, und eine ask-Regel fragt immer nach – genau wie unter So funktionieren Berechtigungen beschrieben. deny- und ask-Regeln auf Organisationsebene bleiben ebenfalls unberührt.

Der Smart-Modus wird schrittweise eingeführt und erscheint daher möglicherweise noch nicht in Ihrer Modusauswahl oder beim Durchschalten mit Shift+Tab.

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, Smart 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 Write(...) erweitern die Sandbox dynamisch für nachfolgende Befehle. Genehmigungen für Read(...) während der Sitzung wirken sich nur auf die eigenen Tools des Agenten aus; durch Read(...)-Ablehnungsregeln ausgeblendete Pfade bleiben während der gesamten Sitzung ausgeblendet.

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 schreibbaren Stammverzeichnissen, Ablehnungsregeln 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:

Ablehnungsregeln — Werden zuerst geprüft. Bei einer Übereinstimmung wird die Aktion sofort blockiert.
Rückfrageregeln — Werden als Zweites geprüft. Bei einer Übereinstimmung werden Sie immer um Bestätigung gebeten (überschreibt alle Erlaubnisregeln).
Erlaubnisregeln — Werden zuletzt geprüft. Bei einer Übereinstimmung wird die Aktion ohne Rückfrage ausgeführt.
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.

Projektkonfiguration
Nutzerkonfiguration
Lokale Überschreibung

// .devin/config.json
{
  "permissions": {
    "allow": [
      "Read(src/**)",
      "Exec(npm run)"
    ],
    "deny": [
      "Exec(rm)"
    ]
  }
}

// ~/.config/devin/config.json
{
  "permissions": {
    "allow": [
      "Read(**)",
      "Exec(git)"
    ]
  }
}

// .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

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.

Write(glob)

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
]

Exec(prefix)

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.

Fetch(pattern)

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
    ]
  }
}

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:

"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

Command-Prompts bieten beide Geltungsbereiche explizit an: „Ja, <cmd>-Befehle in <project> immer erlauben“ speichert die Genehmigung für das aktuelle Projekt, und „Ja, <cmd>-Befehle in allen Projekten immer erlauben“ speichert sie in Ihrer Nutzerkonfiguration, sodass sie überall gilt. Web-Fetch-Prompts für eine bestimmte URL oder Domain bieten zusätzlich die entsprechende Option „Ja, alle Web-Fetches immer erlauben“, mit der das Abrufen mit einem einzigen Schritt auf die Whitelist gesetzt wird.

Einen Befehl vor der Bestätigung bearbeiten

Bestätigungsaufforderungen für Befehle sind nicht auf Ja/Nein beschränkt. Neben den Bestätigungsoptionen bietet eine Befehlsaufforderung Folgendes:

Option	Wirkung
Befehl bearbeiten	Öffnet den vorgeschlagenen Befehl zur direkten Bearbeitung, sodass Sie ihn vor der Ausführung anpassen können
Änderung am Befehl beschreiben	Formuliert den Befehl anhand einer Klartextbeschreibung dessen, was er tun soll, neu, damit Sie ihn vor der Ausführung überprüfen können

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):

Organisations-/Team-Settings (bei Enterprise)
Freigaben auf Sitzungsebene (interaktive Genehmigungen)
Lokale Projektkonfiguration (.devin/config.local.json)
Projektkonfiguration (.devin/config.json)
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(**).

Erste Schritte

Editor-Integrationen

Erweiterbarkeit

Enterprise

Referenz

Changelog

Standardverhalten für Berechtigungen

Smart-Modus

Autonomous-Modus

So funktionieren Berechtigungen

Konfiguration

Syntax für Berechtigungen

Geltungsbereichsbasierte Berechtigungen

Toolbasierte Berechtigungen

Berechtigungen für MCP-Tools

Pfadmuster

Persistenzoptionen

Einen Befehl vor der Bestätigung bearbeiten

Berechtigungen auf MCP-Server-Ebene

Vorrang

Beispiele

Minimales Development-Setup

Volles Vertrauen für ein Projekt

Stark abgesichertes Enterprise

​Standardverhalten für Berechtigungen

​Smart-Modus

​Autonomous-Modus

​So funktionieren Berechtigungen

​Konfiguration

​Syntax für Berechtigungen

​Geltungsbereichsbasierte Berechtigungen

​Toolbasierte Berechtigungen

​Berechtigungen für MCP-Tools

​Pfadmuster

​Persistenzoptionen

​Einen Befehl vor der Bestätigung bearbeiten

​Berechtigungen auf MCP-Server-Ebene

​Vorrang

​Beispiele

​Minimales Development-Setup

​Volles Vertrauen für ein Projekt

​Stark abgesichertes Enterprise

Standardverhalten für Berechtigungen

Smart-Modus

Autonomous-Modus

So funktionieren Berechtigungen

Konfiguration

Syntax für Berechtigungen

Geltungsbereichsbasierte Berechtigungen

Toolbasierte Berechtigungen

Berechtigungen für MCP-Tools

Pfadmuster

Persistenzoptionen

Einen Befehl vor der Bestätigung bearbeiten

Berechtigungen auf MCP-Server-Ebene

Vorrang

Beispiele

Minimales Development-Setup

Volles Vertrauen für ein Projekt

Stark abgesichertes Enterprise