Konfigurationspriorität

Wie globale, projektbezogene und lokale Settings zusammenwirken

Devin CLI lädt Konfigurationen aus mehreren Quellen und führt sie zusammen. Wenn Sie die Prioritätsreihenfolge kennen, können Sie die richtige Konfiguration für Ihr Team und Ihre persönlichen Vorlieben einrichten.

---

​

Konfigurationsschichten

Von der höchsten zur niedrigsten Priorität:

Priorität	Quelle	Hinweise
1 (höchste)	Organisation / Team Settings	Kann nicht überschrieben werden
2	Sitzung (interaktive Genehmigungen)	Nur im Arbeitsspeicher
3	Lokal im Projekt (.devin/config.local.json)	Persönlich, von Git ignoriert
4	Projekt (.devin/config.json)	Mit dem Team geteilt
5 (niedrigste)	Nutzer (~/.config/devin/config.json; %APPDATA%\devin\config.json unter Windows)	Ihre Standardeinstellungen

Wenn dieselbe Einstellung auf mehreren Ebenen definiert ist, setzt sich die Quelle mit der höheren Priorität durch.

---

​

Wann Sie welche Ebene verwenden sollten

Nutzerkonfiguration

Pfad: ~/.config/devin/config.json (%APPDATA%\devin\config.json unter Windows)

Verwenden Sie diese Ebene für persönliche Einstellungen, die überall gelten:

• Bevorzugtes Standardmodell
• Bevorzugtes Theme
• Persönliche MCP-Server (z. B. Ihre eigenen API keys)
• Globale Berechtigungen

{
  "agent": { "model": "opus" },
  "permissions": {
    "allow": ["Read(**)", "Exec(git)"]
  }
}

Projektkonfiguration

Pfad: .devin/config.json

Verwenden Sie diese Ebene für Teamstandards, die im Repository committet werden. Auf dieser Ebene sind nur permissions, mcpServers, read_config_from und hooks verfügbar:

• Gemeinsam genutzte MCP-Server (mit nicht sensibler Konfiguration)
• Team-Berechtigungsrichtlinien
• Importeinstellungen
• Lifecycle Hooks

{
  "permissions": {
    "allow": ["Exec(npm run)", "Read(src/**)"],
    "deny": ["Exec(sudo)"]
  },
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"]
    }
  }
}

Lokale Projektkonfiguration

Pfad: .devin/config.local.json

Verwenden Sie diese Ebene für persönliche Overrides, die nicht committet werden sollten:

• API keys und Secrets
• Persönliche Tool-Einstellungen für dieses Projekt
• Berechtigungs-Overrides

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "ghp_my_personal_token"
      }
    }
  }
}

Lokale Konfigurationsdateien werden über .git/info/exclude automatisch von git ausgeschlossen.

Organization Settings

Verwaltet von Ihrem Enterprise Admin über das Team Settings-Dashboard. Diese Einstellungen können nicht von einzelnen Nutzern überschrieben werden und erzwingen organisationsweite Richtlinien wie Modelleinschränkungen und MCP-Server-Allowlists.

---

​

Was auf jeder Ebene verfügbar ist

Nicht alle Settings können auf Projektebene festgelegt werden. Projektkonfigurationen (.devin/config.json und .devin/config.local.json) unterstützen:

Setting	Nutzerkonfiguration	Projektkonfiguration
permissions	✓	✓
mcpServers	✓	✓
read_config_from	✓	✓
hooks	✓	✓
agent (Modell)	✓	✗
theme_mode	✓	✗
unicode_mode	✓	✗
show_path	✓	✗
include_gitignored_files	✓	✗
sandbox	✓	✗

Settings, die nur für die Nutzerkonfiguration markiert sind, können nur in der Nutzerkonfiguration (~/.config/devin/config.json; unter Windows %APPDATA%\devin\config.json) festgelegt werden und sind nicht Teil der oben beschriebenen Prioritätshierarchie.

---

​

So funktioniert das Zusammenführen

Die obige Rangfolgetabelle gilt nur für Settings, die mehrere Ebenen unterstützen (permissions, mcpServers, read_config_from, hooks).

​

Berechtigungen

Berechtigungslisten werden über mehrere Ebenen hinweg zusammengeführt (kombiniert). Eine Ablehnung auf einer höheren Ebene kann nicht durch eine Erlaubnis auf einer niedrigeren Ebene aufgehoben werden.

Wenn Ihre Organisation zum Beispiel Exec(sudo) ablehnt, hat das Hinzufügen von Exec(sudo) zu Ihrer Nutzer-Erlaubnisliste keine Wirkung — die Ablehnung auf Organisationsebene hat immer Vorrang. Andere Berechtigungen wie Read(**) auf Projektebene werden jedoch normal angewendet.

​

MCP-Server

MCP-Server-Konfigurationen werden nach ihrem Namen zusammengeführt. Ein Server, der auf einer höheren Ebene definiert ist, überschreibt den gleichnamigen Server auf einer niedrigeren Ebene.

Wenn zum Beispiel sowohl Ihre Nutzerkonfiguration als auch die Projektkonfiguration einen “github”-Server definieren, hat die Version aus der Projektkonfiguration Vorrang, da sie eine höhere Priorität als die Nutzerkonfiguration hat.

​

Hooks

Hooks werden aus allen Quellen zusammengeführt und alle ausgeführt. Ein Hook, der in der Nutzerkonfiguration definiert ist, wird zusammen mit Hooks ausgeführt, die in der Projektkonfiguration definiert sind — sie überschreiben sich nicht gegenseitig.

---

​

Erkennung des Projektstammverzeichnisses

Devin CLI ermittelt das Stammverzeichnis Ihres Projekts, indem es ausgehend von Ihrem aktuellen Arbeitsverzeichnis in den übergeordneten Verzeichnissen nach einem .git- oder .jj-Verzeichnis sucht. Die Projektkonfiguration (.devin/) wird aus dem Projektstammverzeichnis geladen.

Wenn Sie verschachtelte .devin/-Verzeichnisse haben (z. B. in einem Monorepo), haben Konfigurationen in Unterverzeichnissen Vorrang vor Konfigurationen in übergeordneten Verzeichnissen.

---

​

Zusammenfassung der Dateierkennung

Datei	Gefunden über	Geteilt?
~/.config/devin/config.json	XDG-Pfad	Nein
.devin/config.json	Ausgehend von cwd nach oben gesucht	Ja (committet)
.devin/config.local.json	Ausgehend von cwd nach oben gesucht	Nein (von Git ignoriert)
.devin/skills/*/SKILL.md	Projektstammverzeichnis	Ja (committet)
~/.config/devin/skills/*/SKILL.md	XDG-Pfad	Nein
AGENTS.md	Projektstammverzeichnis	Ja (committet)
~/.config/devin/AGENTS.md	XDG-Pfad	Nein

Windows: Als ~/.config/devin/ angegebene Pfade verwenden die XDG-Konvention für Linux/macOS. Unter Windows entsprechen sie %APPDATA%\devin\ (in der Regel C:\Users\<YourUser>\AppData\Roaming\devin\).