Skip to main content

Überblick

system.json ist eine optionale, maschinenweite Richtliniendatei, die Administratoren auf verwaltete Geräte verteilen (in der Regel über MDM). Sie befindet sich in einem Systemverzeichnis, in das nur Administratoren schreiben können. Daher können die darin enthaltenen Einstellungen – anders als die Nutzerkonfiguration unter ~/.config/devin/config.json – nicht von Nutzern geändert oder entfernt werden. Verwenden Sie sie, um:
  • Die Authentifizierung auf Ihren Enterprise-Devin-Host und/oder Ihr Konto festzulegen, sodass devin auth login das Menü zur Auswahl der Anmeldemethode überspringt und Konten außerhalb Ihrer Organisation ablehnt.
  • Einen ausgehenden HTTP-Proxy zu erzwingen für die CLI und ihren Updater. Die Enterprise-Einstellung hat Vorrang vor der Nutzerkonfiguration. Nutzer, die in ihrer eigenen Konfiguration ebenfalls einen Abschnitt proxy haben, werden aufgefordert, diesen zu entfernen, bevor die CLI gestartet werden kann – siehe Proxy, bevor Sie einen Proxy bereitstellen.
Die Datei ist optional und additiv: Ist sie nicht vorhanden, verhält sich Devin CLI genau wie auf einem nicht verwalteten Gerät.

Speicherort der Datei

Dies sind dieselben systemweiten, für Administratoren beschreibbaren Verzeichnisse, die Devin Desktop für systemweite Regeln und Hooks verwendet. Stellen Sie die Datei mit root-/Administrator-Eigentümerschaft und schreibgeschützten Berechtigungen für reguläre Nutzer bereit – die CLI liest sie an jedem Speicherort, an dem sie sie findet. Ein für Nutzer beschreibbarer Speicherort unterläuft daher den Zweck der Richtlinie.

Beispiel

system.json wird als striktes JSON geparst — Kommentare und nachgestellte Kommas werden hier nicht unterstützt, anders als in der Nutzer-config.json, die JSON mit Kommentaren verwendet. Der obige Kommentar dient nur zur Angabe des Dateipfads.

Optionsreferenz

Jedes Feld ist unabhängig – legen Sie nur die benötigten fest. Unbekannte Felder werden ignoriert. Daher wendet eine für eine neuere CLI geschriebene Richtlinie ihre bekannten Einstellungen auch bei einer älteren CLI weiterhin an.

enterprise_host

Wenn dieser Wert festgelegt ist, führt devin auth login Folgendes aus:
  1. Überspringt das Menü zur Auswahl der Anmeldemethode und die Subdomain-Abfrage und führt die Authentifizierung direkt beim konfigurierten Host durch.
  2. Lehnt jede Anmeldung ab, bei der das resultierende Konto zu einem anderen Host gehört (oder überhaupt keinem Devin Enterprise), und zeigt eine Meldung mit Verweis auf den richtigen Host an.
  3. Verweigert den Legacy-Windsurf-Anmeldepfad vollständig.
Beim Vergleich wird die Groß- und Kleinschreibung nicht berücksichtigt und das Schema ignoriert. Daher sind acme.devinenterprise.com, ACME.DevinEnterprise.com und https://acme.devinenterprise.com/ gleichwertig. Ein explizites http://-Schema wird bei der Anmeldung beibehalten (nur für Tests nützlich); andernfalls wird https:// angenommen.

account_id

Wenn festgelegt, muss das authentifizierte Konto mit dieser Konto-ID übereinstimmen, auch wenn der Host bereits übereinstimmt — verwenden Sie diese Option, um einen bestimmten Tenant auf einem gemeinsam genutzten Host anzupinnen. Eine Anmeldung, die einem anderen Konto oder keinem Konto zugeordnet wird, wird nach der Kontoüberprüfung abgelehnt. Wenden Sie sich an Ihr Cognition Account Team, wenn Sie nicht sicher sind, welche Konto-ID Sie verwenden sollen. Das Festlegen von account_id unterbindet auch den Legacy-Windsurf-Anmeldepfad, da ein Windsurf-Konto keine Devin-Kontorichtlinie erfüllen kann.

proxy

Legt fest, wie die CLI ihren ausgehenden HTTP/HTTPS-Datenverkehr (API-Aufrufe, Updates, MCP-Server) weiterleitet. Die Konfiguration entspricht dem Abschnitt proxy der Nutzerkonfigurationsdatei: Die Binärdatei devin-updater liest dieselbe Einstellung, sodass Updates im Hintergrund über denselben Proxy wie die CLI erfolgen.
Der Enterprise-Proxy hat Vorrang vor der Nutzerkonfiguration. Es ist ein Fehler, wenn beide Dateien einen Proxy konfigurieren. Wenn ein Nutzer auch einen Abschnitt proxy in seiner config.json hat, beendet sich die CLI beim Start und fordert ihn auf, diesen zu entfernen, anstatt die Einstellung stillschweigend zu ignorieren. Weisen Sie Ihre Nutzer an, alle lokalen Abschnitte proxy zu entfernen, bevor Sie die Richtlinie einführen.

Verhalten und Fehlermodi

Eine fehlerhafte oder nur teilweise verstandene Richtliniendatei deaktiviert die CLI niemals — sie führt lediglich dazu, dass keine Durchsetzung erfolgt — während eine gültige Richtlinie stets durchgesetzt wird: Die Anmelde-Durchsetzung erfolgt bei devin auth login. Zugangsdaten, die bereits auf einem Gerät gespeichert sind, auf dem vor der Bereitstellung der Richtlinie eine Anmeldung erfolgt ist, werden nicht erneut validiert. Stellen Sie system.json daher vor der Einführung der CLI bereit — oder lassen Sie betroffene Nutzer devin auth logout ausführen und sich erneut anmelden. Der Pfad zu system.json kann in Stable-, Next- oder Enterprise-Builds nicht über eine Umgebungsvariable umgeleitet werden, sodass Nutzer die CLI nicht auf eine eigene Richtlinie verweisen können.

Überprüfen der Richtlinie

Auf einem verwalteten Gerät:
Wenn enterprise_host gesetzt ist, sollte das Menü zur Auswahl der Anmeldemethode nicht angezeigt werden und die ausgegebene Anmelde-URL sollte auf Ihrem konfigurierten Host verweisen. Bestätigen Sie anschließend die resultierende Sitzung:
Bei einer Anmeldung mit einem Konto, das nicht der Richtlinie entspricht, wird in einer eindeutigen Meldung der von Ihrer Organisation erforderliche Host oder das erforderliche Konto genannt. system.json umfasst Richtlinien auf Geräteebene, die vor oder während der Anmeldung vorhanden sein müssen. Die meisten anderen organisationsweiten Steuerungsmöglichkeiten — Modelle, MCP-Server und Registries, Terminal-Berechtigungen, Sandbox-Erzwingung, Websuche — werden serverseitig in den Team Settings verwaltet und gelten automatisch, sobald sich ein Nutzer anmeldet.

Weiterführende Informationen