Couches de configuration
De la priorité la plus élevée à la plus faible :
Lorsque le même paramètre est défini à plusieurs niveaux, c’est la source de priorité la plus élevée qui l’emporte.
Les serveurs MCP suivent le même ordre de priorité, mais se trouvent dans des fichiers dédiés à chaque niveau :
~/.config/devin/mcp_config.json (%APPDATA%\devin\mcp_config.json sous Windows), .devin/mcp_config.json et .devin/mcp_config.local.json. Dans les versions CLI antérieures à v3000.3 (la version Local 3.6), les serveurs MCP sont plutôt stockés dans la clé mcpServers des fichiers config.json ; les versions plus récentes les migrent automatiquement vers les fichiers dédiés au démarrage.Quand utiliser chaque niveau
Configuration utilisateur
Configuration utilisateur
Chemin :
~/.config/devin/config.json (%APPDATA%\devin\config.json sous Windows)À utiliser pour les préférences personnelles qui s’appliquent partout :- Préférence de modèle par défaut
- Préférence de thème
- Serveurs MCP personnels (p. ex. vos propres API keys)
- Autorisations globales
Configuration du projet
Configuration du projet
Chemin :
.devin/config.jsonÀ utiliser pour les standards de Team versionnés dans le dépôt. Seuls permissions, read_config_from et hooks sont disponibles dans .devin/config.json ; les serveurs MCP se trouvent dans .devin/mcp_config.json à ses côtés :- Serveurs MCP partagés (avec une configuration non secrète, dans
.devin/mcp_config.json) - Politiques d’autorisations de Team
- Settings d’importation
- Hooks de cycle de vie
Configuration locale du projet
Configuration locale du projet
Chemin :
.devin/config.local.jsonÀ utiliser pour les dérogations personnelles qui ne doivent pas être versionnées :- API keys et secrets (les serveurs MCP se trouvent dans
.devin/mcp_config.local.json) - Préférences personnelles d’outil pour ce projet
- Dérogations d’autorisations
Settings de l’organisation
Settings de l’organisation
Gérés par votre administrateur Enterprise via le tableau de bord des Settings du Team. Ces paramètres ne peuvent pas faire l’objet de dérogations par les utilisateurs individuels et appliquent des politiques à l’échelle de l’organisation, comme des restrictions sur les modèles et des listes d’autorisation de serveurs MCP.
Ce qui est disponible à chaque niveau
Les configurations du projet (.devin/config.json et .devin/config.local.json) ne prennent en charge qu’un sous-ensemble de Settings. Le tableau ci-dessous indique quels Settings sont disponibles à chaque niveau (mcpServers se trouve dans les fichiers mcp_config.json dédiés à chaque niveau, et non dans config.json) :
Les Settings marqués comme disponibles uniquement dans la configuration utilisateur ne peuvent être définis que dans la configuration utilisateur (
~/.config/devin/config.json ; %APPDATA%\devin\config.json sous Windows) et n’entrent pas dans la hiérarchie de priorité ci-dessus.
Comment fonctionne la fusion
Le tableau de priorité ci-dessus ne s’applique qu’aux Settings qui prennent en charge plusieurs niveaux (permissions, mcpServers, read_config_from, hooks).
Autorisations
Les listes d’autorisations sont cumulées (combinées) entre les différents niveaux. Un refus à un niveau supérieur ne peut pas être annulé par une autorisation à un niveau inférieur. Par exemple, si votre organisation refuseExec(sudo), ajouter Exec(sudo) à votre liste d’autorisations utilisateur n’a aucun effet — le refus défini au niveau de l’organisation l’emporte toujours. En revanche, d’autres autorisations comme Read(**) au niveau du projet s’appliquent normalement.
Serveurs MCP
Les configurations des serveurs MCP sont fusionnées en fonction de leur nom. Un serveur défini à un niveau supérieur prend le pas sur un serveur du même nom défini à un niveau inférieur. Par exemple, si votre configuration utilisateur et la configuration du projet définissent toutes deux un serveur “github”, c’est la version de la configuration du projet qui l’emporte, car elle est prioritaire sur la configuration utilisateur.Hooks
Les hooks sont collectés à partir de toutes les sources et s’exécutent tous. Un hook défini dans la configuration utilisateur s’exécute en parallèle des hooks définis dans la configuration du projet — ils ne se remplacent pas les uns les autres.Détection de la racine du projet
Devin CLI détecte la racine de votre projet en recherchant un répertoire.git ou .jj en remontant depuis votre répertoire de travail actuel. La configuration du projet (.devin/) est chargée depuis la racine du projet.
Si vous avez des répertoires
.devin/ imbriqués (p. ex. dans un monorepo), les configurations des sous-répertoires sont prioritaires sur celles des répertoires parents.Résumé de la détection des fichiers
Windows : Les chemins affichés sous la forme
~/.config/devin/ utilisent la convention XDG pour Linux/macOS. Sous Windows, ils correspondent à %APPDATA%\devin\ (généralement C:\Users\<YourUser>\AppData\Roaming\devin\).