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.
Mit teamweiten Einstellungen können Enterprise-Admins die Nutzung von Devin CLI in ihrer gesamten Organization steuern.
- Devin Enterprise-Admins können diese Einstellungen im Devin-Dashboard für Kunden unter Settings → Enterprise → Windsurf (
app.devin.ai/org/{orgName}/settings/windsurf) verwalten. Diese Self-Service-Option steht Admins mit Zugriff auf die Enterprise-Einstellungen zur Verfügung.
- Windsurf Enterprise-Admins können diese Einstellungen im Windsurf-Dashboard unter https://windsurf.com/team/cli-settings verwalten.
Nur die Devin-CLI-spezifischen Einstellungen auf diesen Seiten gelten für Devin CLI. Allgemeine Windsurf Team Settings gelten für Windsurf und nicht unbedingt auch für Devin CLI, sofern sie nicht ebenfalls auf der Einstellungsseite für Devin CLI aufgeführt sind.
- Bestimmte Modelle freigeben — Beschränken Sie den Zugriff der Nutzer auf eine kuratierte Liste genehmigter Modelle
- Alle Modelle zulassen — Geben Sie Nutzern Zugriff auf alle verfügbaren Modelle
Klicken Sie auf Konfigurieren, um den Modellzugriff für jede Kategorie zu verwalten.
Sie können auch ein teamweites Standardmodell anpinnen, das Devin CLI für neue Sitzungen verwendet. Das ist dieselbe Einstellung, die Windsurf für sein Standardmodell nutzt, sodass eine einmalige Konfiguration für beide Bereiche gilt.
- Wenn kein teamweites Standardmodell festgelegt ist, verwendet Devin CLI sein integriertes Standardmodell.
- Wenn das angepinnte Standardmodell nicht in der obigen Liste der zulässigen Modelle enthalten ist, greift Devin CLI auf das integrierte Standardmodell zurück — die Allowlist hat immer Vorrang.
- Einzelne Nutzer können während einer Sitzung weiterhin das Modell wechseln; diese Einstellung steuert nur das Startmodell für neue Sitzungen.
Enterprise-Admins können das Standardmodell auf der Seite Windsurf Team Settings, auf der Seite Devin CLI Settings oder auf der kundenseitigen Devin Enterprise-Settings-Seite unter app.devin.ai/org/{orgName}/settings/windsurf konfigurieren.
Erlauben Sie dem Devin CLI-Agenten, Websuchen im öffentlichen Internet durchzuführen. Dies hat keinen Einfluss auf die Fähigkeit des Agenten, bestimmte URLs zu lesen, da dies lokal auf dem Rechner des Nutzers erfolgt. Dieses Tool ist für Enterprise-Teams standardmäßig deaktiviert.
Steuern Sie, ob Ihre Nutzer MCP-Tools (Model Context Protocol) verwenden können.
- Ein-/Ausschalten — Die Nutzung von MCP-Servern vollständig aktivieren oder deaktivieren
- Zugelassene MCP-Server — Geben Sie an, mit welchen MCP-Servern sich Nutzer verbinden dürfen. Wenn keine Server hinzugefügt werden, sind standardmäßig alle Server zugelassen. Klicken Sie auf Server hinzufügen, um den Zugriff auf bestimmte Server zu beschränken.
Konfigurieren Sie vom Team vorgegebene Berechtigungsregeln für die Nutzung der Devin CLI. Diese Regeln haben die höchste Priorität und können nicht durch lokale oder Projektkonfigurationen einzelner Nutzer überschrieben werden.
Klicken Sie auf Configure, um den Berechtigungseditor zu öffnen. Für die Konfiguration ist ein JSON-Objekt mit drei Feldern erforderlich:
{
"deny": [
"exec"
],
"ask": [],
"allow": [
"Read(~/my-repository/**)"
]
}
deny — Aktionen, die vollständig blockiert werden (hat höchste Priorität)ask — Aktionen, für die der Nutzer immer um Genehmigung gebeten wirdallow — Aktionen, die automatisch ohne Nachfrage genehmigt werden
Berechtigungen können auf dem Geltungsbereich basieren oder toolbasiert sein:
| Type | Format | Example |
|---|
| Dateilesen | Read(/path) | Read(~/sensitive/**) |
| Dateischreiben | Write(/path) | Write(.env*) |
| Befehlsausführung | Exec(cmd) | Exec(rm), Exec(sudo) |
| HTTP-Abruf | Fetch(url) | Fetch(https://internal.api/*) |
| Toolbasiert | Tool-Name | read, edit, exec |
Verwenden Sie vom Team erzwungene deny-Regeln, um Aktionen in Ihrer gesamten Organisation zu unterbinden, z. B. den Zugriff auf sensible Verzeichnisse oder gefährliche Befehle wie rm -rf oder sudo zu blockieren.
--sandbox in Ihrer gesamten Organisation fest:
- Optional (Standard) — Nutzer entscheiden selbst, ob sie
--sandbox übergeben. Keine Erzwingung.
- Required — Das Flag
--sandbox wird für alle Nutzer erzwungen, auch wenn sie es nicht in der Befehlszeile übergeben. Alle CLI-Sitzungen werden mit einer Sandbox auf Betriebssystemebene ausgeführt, die Lese-/Schreib-Berechtigungsbereiche durchsetzt.
Ein zukünftiger Modus Strict könnte die Sandbox-Konfiguration vollständig sperren und Nutzer daran hindern, Sandbox-Einstellungen zu ändern.
Wenn die Sandbox aktiv ist:
- Schreibbare Pfade werden aus den gewährten
Write(...)-Berechtigungsbereichen plus dem Workspace-Verzeichnis abgeleitet
- Lesbare Pfade werden aus den gewährten
Read(...)-Bereichen abgeleitet (Plattform-Standards wie /usr/bin sind immer lesbar)
- Während einer Sitzung gewährte Bereiche erweitern die Sandbox dynamisch für nachfolgende Befehle
Wenn die Ermittlung der Sandbox fehlschlägt (z. B. weil die Sandboxing-Tools auf der Plattform des Nutzers nicht verfügbar sind), wird die CLI den Start verweigern, statt ohne Sandbox zu laufen. Dieses Fail-Closed-Verhalten gilt sowohl dann, wenn die Sandbox über diese Team-Einstellung aktiviert wurde, als auch dann, wenn der Nutzer --sandbox direkt übergibt. So wird sichergestellt, dass die beabsichtigte Sicherheitswirkung nie stillschweigend umgangen wird.Wenn dies durch Enterprise erzwungen wird, sehen Nutzer eine Fehlermeldung mit dem Hinweis, ihren Team-Administrator zu kontaktieren. Wenn die Sandbox vom Nutzer aktiviert wurde, schlägt die Fehlermeldung vor, ohne --sandbox zu starten, um ohne Isolierung auf Betriebssystemebene fortzufahren.Häufige Ursachen für ein Fehlschlagen der Sandbox-Ermittlung:
- Windows: Sandboxing auf Betriebssystemebene wird unter Windows derzeit nicht unterstützt. Sitzungen unter Windows schlagen sofort fehl, wenn
--sandbox übergeben wird oder wenn die Sandbox-Erzwingung auf Required gesetzt ist, auch wenn die CLI als ACP-Server innerhalb einer IDE läuft (z. B. Windsurf).
- Linux: Sandboxing erfordert, dass
bubblewrap (bwrap) und socat installiert sind. Wenn diese fehlen, schlagen Sitzungen sofort fehl und es werden Installationsanweisungen angezeigt.
- Fehler bei Berechtigungsbereichen: Ungültige Pfade in Berechtigungsbereichen, die nicht aufgelöst werden können.
Stellen Sie sicher, dass alle Zielmaschinen entsprechend eingerichtet sind, bevor Sie den Sandbox-Erzwingungsmodus in Ihrer gesamten Organisation auf Required setzen. Wenn Nutzer Windows verwenden, können sie die CLI erst wieder ausführen, wenn Sandboxing auf Betriebssystemebene unter Windows unterstützt wird oder die Richtlinie auf Optional gelockert wird.
-
Domain-Allowlist — Wenn sie festgelegt ist, sind über den Sandbox-Netzwerk-Proxy nur die Domains in dieser Liste erreichbar. Diese Liste ist verbindlich: Sie ersetzt sämtliche lokal konfigurierten
allowed_domains der Nutzer in ihrer Sandbox-Konfiguration vollständig. Nutzer können keine zusätzlichen Domains hinzufügen, um Admin-Einschränkungen zu umgehen.
-
Domain-Denylist — Domains, die immer blockiert werden. Auf Enterprise-Ebene gesperrte Domains sind additiv: Sie werden mit den lokalen
denied_domains des Nutzers zusammengeführt, wodurch die kombinierte Liste restriktiver wird.
Informationen zur Syntax von Domain-Mustern (z. B. *.example.com, **.example.com) finden Sie in der Referenz zur Sandbox-Konfiguration.
So wirken Enterprise- und Nutzer-Domain-Listen zusammen:
| Szenario | Enterprise-Konfiguration | Nutzerkonfiguration | Effektives Ergebnis |
|---|
| Admin legt eine Allowlist fest | allowed_domains: ["github.com"] | allowed_domains: ["npmjs.org"] | Nur github.com ist erlaubt (Enterprise ersetzt die Nutzerliste) |
| Admin legt eine Denylist fest | denied_domains: ["evil.com"] | denied_domains: ["risky.io"] | Sowohl evil.com als auch risky.io werden blockiert (zusammengeführt) |
| Keine Admin-Allowlist | allowed_domains: [] | allowed_domains: ["github.com"] | Die Allowlist des Nutzers wird verwendet |
Da die lokalen denied_domains des Nutzers beibehalten und additiv zusammengeführt werden, kann ein Nutzer eine Domain sperren, die in der Enterprise-Allowlist enthalten ist. Das ist beabsichtigt: Die kombinierte Wirkung ist immer restriktiver, niemals weniger restriktiv. Falls dies zu Zugriffsproblemen führt, sollte der Nutzer den widersprüchlichen Eintrag aus seiner lokalen Konfiguration entfernen.
Kombinieren Sie die Sandbox-Erzwingung mit verweigernden Team-Berechtigungsregeln (z. B. Write(/etc)), damit Agenten sensible Verzeichnisse weder auf Berechtigungs- noch auf Betriebssystemebene ändern können. Berechtigungsregeln zum Verweigern hindern den Agenten bereits daran, die Aktion überhaupt zu versuchen, während die Sandbox eine zweite Durchsetzungsschicht auf Betriebssystemebene bietet.
„Install Devin CLI“ in der Windsurf Command Palette anzeigen
Cmd+Shift+P unter macOS oder Ctrl+Shift+P unter Windows/Linux) und den Befehl Install Devin CLI ausführen, um die devin-Binärdatei zu ihrem PATH hinzuzufügen.
Diese Einstellung ist in den Windsurf Enterprise- und Devin Enterprise-Plänen verfügbar und standardmäßig deaktiviert.
