Variables d'environnement : les « interrupteurs généraux » cachés en arrière-plan
📚 Navigation de la série : L'article précédent 41 Tâches parallèles vous a appris comment diviser le travail pour faire tourner plusieurs Claude en même temps. Cet article plonge sous la surface — ces « interrupteurs généraux » qui contrôlent comment Claude Code se connecte aux modèles, le délai d'expiration ou s'il faut remonter des données, tout dépend de l'activation des variables d'environnement. Ils ne se trouvent dans aucun menu, ils sont cachés dans votre shell et votre
settings.json. Aujourd'hui, nous allons faire le tour de ces interrupteurs et comprendre comment les configurer.
On dit souvent que les variables d'environnement sont réservées aux « joueurs confirmés », mais pour être honnête, cette idée a induit beaucoup de monde en erreur.
Trop de gens configurent le modèle, le proxy et le délai d'expiration manuellement à chaque début de session avec /model, modifiant tout à la main, pour devoir tout recommencer lors de la session suivante. Quand on leur demande pourquoi ils ne le fixent pas une fois pour toutes, la réponse is souvent : « Les variables d'environnement, ça a l'air trop technique, j'ai peur de tout casser ».
Pourtant, si vous regardez les quarante et un articles précédents — la configuration de l'API key dans le n°04, la connexion aux modèles domestiques dans le n°05, la gestion du contexte dans le n°19, la désactivation de la télémétrie dans le n°21... au fond, presque toutes ces actions reposent sur le même mécanisme sous-jacent : les variables d'environnement. Vous les utilisez déjà depuis longtemps, c'est juste que personne ne les a présentées ensemble à plat.
Disons-le ainsi : les variables d'environnement ne sont pas réservées aux « experts », mais sont plutôt cette rangée d'interrupteurs généraux que l'on « règle une fois pour toutes pour en bénéficier à vie ». En avoir peur vient simplement du fait que personne ne vous a dit lesquels sont couramment utilisés, et quelles sont les conséquences si vous vous trompez. Aujourd'hui, nous allons lever le voile sur tout cela.
À la fin de cet article, vous obtiendrez :
- Une explication en une phrase de ce que gèrent réellement les variables d'environnement dans Claude Code, et pourquoi cela vaut la peine d'y consacrer dix minutes
- Une table claire indiquant quand utiliser les three méthodes de configuration (temporaire dans le shell / permanente dans le fichier de configuration du shell / champ
envdu fichiersettings.json) - La portée de chacune des quatre catégories de fichiers
settings.jsonet lesquels doivent être poussés sur git ou non — en lien direct avec l'article 31 - Une liste des « variables d'environnement indispensables » : connexion, délai d'expiration, confidentialité, répertoire de configuration, avec valeurs par défaut et conseils pour éviter les pièges
- En cas de conflit lorsqu'une même option peut être définie à la fois par une variable d'environnement et par un champ de configuration, qui a le dernier mot (règles de priorité)
- Un cas pratique à suivre pas à pas avec le résultat attendu : configurer vous-même une variable et vérifier qu'elle est bien active
01 D'abord, comprendre : que gèrent réellement les variables d'environnement dans Claude Code
Commençons par la conclusion : les variables d'environnement sont un ensemble d'« interrupteurs clé-valeur » lus par Claude Code au démarrage, servant à définir ses comportements de base tels que la connexion aux modèles, l'authentification, les délais d'expiration et la transmission des données.
La plupart des fonctionnalités que vous avez utilisées auparavant — changer de modèle avec /model, connecter des services avec claude mcp add, ajuster les paramètres avec /config — sont généralement des réglages temporaires effectués en cours de session. Cependant, for certains comportements, vous souhaitez qu'ils soient appliqués à chaque démarrage sans intervention manuelle : par exemple, « je passe toujours par l'adresse de mon proxy personnalisé », « je prolonge le délai d'expiration de toutes mes requêtes à 20 minutes » ou « cette machine ne doit jamais transmettre de télémétrie ». Ce sont ces règles de base stables qui sont régies par les variables d'environnement.
La documentation officielle le résume ainsi :
Les variables d'environnement peuvent contrôler le comportement de Claude Code, comme le choix du modèle, l'authentification, le routage des requêtes et l'activation des fonctionnalités.
Analogie : les boutons de préréglage d'une machine à café. Avec une machine à café programmable, vous pouvez ajuster les paramètres à chaque tasse — quantité d'eau, intensité, ajout de lait ; ou vous pouvez enregistrer votre café préféré sous un « profil personnalisé », pour l'obtenir d'un simple clic car la machine garde les paramètres en mémoire. Les variables d'environnement fonctionnent de la même manière : elles permettent de figer les réglages que vous souhaitez appliquer systématiquement, afin que Claude Code les lise dès le démarrage sans que vous ayez à les ajuster manuellement à chaque fois.
Dans la pratique, vous y penserez très probablement dans les cas suivants :
- « J'ai connecté DeepSeek et je ne veux pas spécifier le modèle manuellement à chaque fois » — écrivez le modèle et l'adresse dans les variables d'environnement (le fonctionnement sous-jacent décrit dans l'article 05).
- « Le réseau de mon entreprise est lent, et le délai d'expiration par défaut de 10 minutes is souvent insuffisant » — une seule variable permet de prolonger ce délai.
- « C'est une machine professionnelle et la conformité exige de ne transmettre aucune télémétrie » — une variable permet de tout désactiver (mentionné dans l'article 21).
- « J'ai deux comptes, un professionnel et un personnel, et je veux les séparer pour éviter toute interférence » — une variable permet de basculer de répertoire de configuration.
Vous voyez ? Ce sont tous des besoins de type « configurer une fois, appliquer à long terme ». Les variables d'environnement sont précisément conçues pour cela.
💡 Résumé en une phrase : Les variables d'environnement sont un ensemble d'« interrupteurs généraux clé-valeur » lus par Claude Code au démarrage pour gérer les comportements de base (connexion, authentification, délai d'expiration, confidentialité) ; leur intérêt réside dans la fixation définitive des paramètres récurrents afin d'éviter de les configurer manuellement à chaque fois.
02 Où configurer : trois méthodes, de « juste pour cette fois » à « actif en permanence »
Maintenant que vous savez ce qu'elles gèrent, passons à la question la plus concrète : où les configurer ? Il existe trois emplacements possibles, et la différence tient à un critère simple : combien de temps et qui la configuration va-t-elle impacter ?
La documentation officielle est très claire à ce sujet :
在 shell 中设置的变量仅在该终端会话期间有效，而在设置文件中的变量在每次运行
claude时都适用。
Voici les three méthodes classées de la portée la plus restreinte à la plus large, pour vous aider à choisir :
Méthode 1 : Définition temporaire dans le shell (ne concerne que ce terminal)
Avant de lancer claude, utilisez export dans votre terminal. Cela ne s'applique qu'à la fenêtre de terminal active, et disparaît dès que vous la fermez.
macOS / Linux / WSL :
export API_TIMEOUT_MS="1200000"
claudeWindows PowerShell :
$env:API_TIMEOUT_MS = "1200000"
claudeCette option est idéale pour « faire un essai rapide » — augmenter temporairement un délai d'expiration, changer momentanément d'adresse, puis fermer le terminal sans laisser de trace.
Méthode 2 : Écriture dans le fichier de configuration du shell (s'applique à chaque fois sur cette machine)
Si vous souhaitez que ces variables soient appliquées à chaque ouverture de terminal, ajoutez la ligne export dans le fichier de configuration de votre shell. Sur Mac, il s'agit par défaut de ~/.zshrc, et sur de nombreuses distributions Linux, de ~/.bashrc :
# 加到 ~/.zshrc 末尾
export API_TIMEOUT_MS="1200000"Enregistrez le fichier puis ouvrez un nouveau terminal (ou exécutez source ~/.zshrc) pour appliquer les changements. C'est la solution pour imposer un comportement à tous vos projets et terminaux sur cette machine.
Sur Windows, pour rendre la configuration persistante, utilisez
setx API_TIMEOUT_MS "1200000"(CMD) ou[Environment]::SetEnvironmentVariable("API_TIMEOUT_MS", "1200000", "User")(PowerShell), puis ouvrez un nouveau terminal pour que cela prenne effet.
Méthode 3 : Écriture dans le champ env de settings.json (lié à la configuration, indépendant du mode de démarrage)
La troisième méthode, qui est aussi la plus courante, consiste à écrire dans la clé env de settings.json. La documentation officielle en souligne les avantages :
Claude Code 在启动时直接从文件读取它们，因此无论如何启动
claude，它们都会生效。
{
"env": {
"API_TIMEOUT_MS": "1200000",
"BASH_DEFAULT_TIMEOUT_MS": "300000"
}
}Le chemin d'accès et la syntaxe de ce fichier ont déjà été abordés dans l'article 31 consacré à
settings.json. Retenez simplement ceci :env是它专门留给环境变量的那个口子，把变量写这儿，跟你怎么敲claude无关，它都读得到。
Voici un comparatif rapide pour choisir la bonne méthode :
| Méthode de configuration | Portée | Persiste après fermeture du terminal | Idéal pour |
|---|---|---|---|
export temporaire dans le shell | Terminal actif uniquement | ❌ Non | « Faire un test ponctuel » |
Écrit dans ~/.zshrc, etc. | Tous les terminaux de la machine | ✅ Oui | « Comportement global sur ma machine personnelle » |
Écrit dans le champ env de settings.json | Portée propre au fichier de configuration | ✅ Oui | « Lié à un projet/une équipe, s'applique à tous » |
Une bonne habitude à prendre : testez d'abord la variable avec un export temporaire dans le shell ; une fois confirmée, déplacez-la dans la clé env de settings.json. Pourquoi privilégier settings.json plutôt que ~/.zshrc ? En raison de la hiérarchie des fichiers présentée dans la section suivante : settings.json vous permet de contrôler précisément si une variable s'applique uniquement à vous, à toute l'équipe ou seulement à ce projet, ce que ~/.zshrc ne permet pas de distinguer.
💡 Résumé en une phrase : Les trois méthodes de configuration se distinguent par leur portée : shell 临时
export（就这一次）、写进~/.zshrc（本机全局）、写进settings.json的env（跟配置走、跟启动方式无关）；临时试探用第一种，长期生效推荐第三种。
03 Les quatre types de fichiers settings.json : leur portée et leur inclusion dans git
Nous avons vu dans la section précédente que la clé env de settings.json est le moyen recommandé. Cependant, il y a un piège classique pour les débutants : il n'y a pas qu'un seul fichier settings.json, mais quatre types différents. Déclarer votre variable dans l'un ou l'autre modifie radicalement sa portée (qui est impacté).
Ce sujet a été détaillé dans l'article 31, mais nous y revenons ici sous l'angle des variables d'environnement, car les conséquences d'une erreur sont bien réelles : vous pensiez configurer un proxy uniquement pour vous, mais vous l'avez accidentellement poussé dans git, perturbant ainsi toute votre équipe.
Analogie : note d'information sur le tableau d'affichage de l'entreprise vs post-it personnel. Si la comptabilité affiche « remboursement de taxi plafonné à 50 € », toute l'entreprise doit s'y conformer : c'est une règle publique. Si vous écrivez sur un post-it à votre bureau « ne pas me faire rembourser mes cafés perso ce mois-ci », c'est une note privée qui ne concerne que vous. Choisir le bon fichier pour vos variables d'environnement revient à décider si vous l'affichez au tableau ou si vous l'écrivez sur votre post-it.
Ce tableau officiel détaille précisément la portée de chaque fichier :
| Fichier | S'applique à |
|---|---|
~/.claude/settings.json | Vous, dans tous les projets |
.claude/settings.json | Quiconque travaille sur le projet, suivi par le contrôle de version |
.claude/settings.local.json | Vous, uniquement pour ce projet, non suivi |
| Paramètres managés | Tout le monde dans l'organisation, déployés par l'administrateur |
En clair, retenez ces quatre cas :
~/.claude/settings.json— Dans votre répertoire personnel, pour « mes préférences personnelles sur tous les projets »..claude/settings.json(racine du projet) — Pour « tout le monde travaillant sur ce projet », et il est inclus dans git pour que vos collaborateurs le récupèrent. Les règles d'équipe se placent ici..claude/settings.local.json(racine du projet) — Pour « moi uniquement, sur ce projet précis », et il n'est pas inclus dans git (l'extension.localest ignorée par défaut). C'est là que vont vos identifiants privés et vos réglages temporaires personnels.- Paramètres managés — Déployés de manière centralisée par les administrateurs pour toute l'organisation. Vous ne pouvez généralement pas les modifier et n'avez pas à les configurer.
C'est un piège classique dans lequel il est facile de tomber. En connectant une passerelle personnalisée, on peut être tenté d'écrire ANTHROPIC_BASE_URL avec une adresse contenant un token personnel dans le fichier .claude/settings.json à la racine du projet, puis de faire un git commit sans vérifier le diff. Une fois poussée, cette adresse privée (contenant potentiellement vos identifiants) devient publique pour quiconque accède au dépôt. Retenez cette règle d'or : toute variable à caractère strictement personnel (adresse privée, répertoire de configuration propre) doit impérativement aller dans le fichier .local exclu de git. Seules les options communes à toute l'équipe doivent être placées dans .claude/settings.json.
| Nature de la variable | Fichier recommandé |
|---|---|
| Mes préférences personnelles, communes à tous les projets | ~/.claude/settings.json (répertoire personnel) |
| Règles communes à l'équipe, à partager dans le projet | .claude/settings.json (inclus dans git) |
| Variables privées, avec identifiants, propres à ce projet | .claude/settings.local.json (❌ non inclus dans git) |
💡 Résumé en une phrase : Les fichiers
settings.jsonse divisent en quatre catégories. Le choix du fichier détermine la portée de la variable : le répertoire personnel pour votre configuration globale, lesettings.jsonà la racine du projet (suivi par git) pour toute l'équipe, et le fichier.local(exclu de git) pour vous seul. Ne mettez jamais de variables contenant des identifiants personnels dans un fichier suivi par git.
03 Les variables d'environnement indispensables : connexion, délai d'expiration, confidentialité, répertoires
Pour être honnête, la liste officielle des variables d'environnement est impressionnante et un peu intimidante — elle en contient des centaines, allant d'AWS Bedrock aux exportateurs OpenTelemetry, dont vous n'aurez probablement jamais besoin. Dans cette section, nous n'allons pas faire d'inventaire exhaustif, mais sélectionner la dizaine de variables que vous rencontrerez réellement, réparties en quatre catégories. Pour chacune, nous préciserons son rôle, sa valeur par défaut et le moment opportun pour la modifier.
Groupe 1 : Connexion et authentification (comment se connecter au modèle)
Ce groupe constitue la base des articles 04 et 05. Voici les trois variables clés :
ANTHROPIC_API_KEY # 你的 API 密钥
ANTHROPIC_BASE_URL # 把请求改道到代理或网关
ANTHROPIC_MODEL # 默认用哪个模型ANTHROPIC_API_KEY— Votre clé API. Il y a un piège classique ici, documenté explicitement : si cette clé est définie, Claude Code l'utilisera en priorité, même si vous êtes connecté avec un abonnement actif (Pro / Max / Team / Enterprise). Pour repasser sur votre abonnement, vous devez supprimer la clé avecunset ANTHROPIC_API_KEY. Remarque : en mode interactif, Claude Code affichera une invite de confirmation pour vous demander d'autoriser ou de refuser l'utilisation de cette clé, avec la possibilité de mémoriser ce choix pour la suite ; en mode non interactif (-p), elle sera utilisée directement sans confirmation. C'est un piège très fréquent : vous pensez utiliser votre abonnement Max, mais vos appels sont facturés via l'API, pour vous rendre compte après recherche qu'une ligneexport ANTHROPIC_API_KEYtraînait dans votre~/.zshrc(voir l'article 04 sur le choix entre abonnement et clé API).ANTHROPIC_BASE_URL— Permet de rediriger les requêtes API vers votre proxy ou passerelle. C'est la variable centrale pour utiliser des modèles domestiques ou passer par un relais personnalisé (le composant principal de la configuration décrite dans l'article 05).ANTHROPIC_MODEL— Spécifie le modèle par défaut. Attention à sa priorité : l'option--modelet la commande/modelen session prévaudront sur cette variable (détails dans la section suivante).
Groupe 2 : Délai d'expiration (à ajuster si les requêtes échouent trop vite)
Lorsque le réseau est lent ou que vous passez par un proxy éloigné, le délai d'expiration est le paramètre le plus fréquemment ajusté. Voici les deux plus courants :
| Variable | Rôle | Valeur par défaut |
|---|---|---|
API_TIMEOUT_MS | Délai d'expiration d'une requête API unique | 600000 (10 minutes) |
BASH_DEFAULT_TIMEOUT_MS | Délai d'expiration par défaut pour les commandes bash longues | 120000 (2 minutes) |
API_TIMEOUT_MS— Durée après laquelle une requête API est considérée en échec. Conseil officiel : augmentez-la si votre connexion est lente ou si vous utilisez un proxy. Cependant, attention à ne pas saisir n'importe quoi : la valeur maximale est2147483647. Dépasser cette limite provoque un dépassement de capacité (overflow) du minuteur sous-jacent, entraînant l'échec immédiat de toutes les requêtes (ajouter un zéro de trop par inattention est une erreur classique qui provoque des erreurs instantanées difficiles à diagnostiquer).BASH_DEFAULT_TIMEOUT_MS— Temps alloué par défaut à Claude pour exécuter des commandes longues (comme l'installation de dépendances ou le lancement d'un build). Par défaut fixé à 2 minutes, augmentez-le si vos builds complexes prennent plus de temps.
Groupe 3 : Confidentialité et télémétrie (conformité / environnements sécurisés)
Déjà évoquées dans l'article 21 sur la sécurité, ces variables contrôlent l'envoi de données vers l'extérieur :
DISABLE_TELEMETRY=1 # 关掉遥测上报
DO_NOT_TRACK=1 # 同上，跨工具通用的约定DISABLE_TELEMETRY— Définie à1pour désactiver la télémétrie. Bien que la documentation officielle précise que les données de télémétrie ne contiennent ni votre code, ni vos chemins de fichiers, ni vos commandes bash, l'activation de cette option is recommandée dans les environnements aux exigences de conformité strictes.DO_NOT_TRACK— Définie à1, elle équivaut àDISABLE_TELEMETRY. Il s'agit d'une convention standard respectée par de nombreux CLI de développement ; la configurer une fois permet de l'appliquer à d'autres outils.
Il existe également une option globale :
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1. La documentation indique qu'elle équivaut à activer simultanémentDISABLE_AUTOUPDATER,DISABLE_FEEDBACK_COMMAND,DISABLE_ERROR_REPORTINGetDISABLE_TELEMETRY. C'est idéal pour couper tout trafic non essentiel d'un seul coup dans les environnements hautement sécurisés ou isolés.
Groupe 4 : Multi-comptes et gestion du contexte (avancé mais utile)
Deux variables très utiles que nous vous recommandons vivement d'apprendre à utiliser :
CLAUDE_CONFIG_DIR— Permet de surcharger le répertoire de configuration (par défaut~/.claude). Tous les paramètres, identifiants, historiques de session et plug-ins y sont stockés. Son utilité principale est de gérer plusieurs comptes en parallèle. L'exemple officiel est très parlant :
# 给工作账号开个独立配置目录，互不干扰
alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'Vous pouvez ainsi séparer vos comptes professionnel et personnel : claude chargera votre configuration personnelle par défaut, tandis que claude-work lancera une session avec des paramètres et un état de connexion totalement isolés. L'historique, les identifiants et les configurations MCP des deux environnements resteront parfaitement distincts.
DISABLE_AUTO_COMPACT— Définie à1pour désactiver la compression automatique lorsque la limite de contexte est presque atteinte (mécanisme détaillé dans l'article 19). La commande manuelle/compactreste disponible. À utiliser si vous souhaitez contrôler manuellement le moment de la compression ; la plupart des utilisateurs peuvent conserver le réglage par défaut.
⚠️ Rappel important : La documentation est catégorique — Claude Code 只在「启动时」读环境变量。所以你改完任何变量（无论改 shell 还是改
settings.json），都得退出claude重开，新值才生效。改完没反应，十有八九是没重启。
💡 Résumé en une phrase : Les variables les plus courantes appartiennent à quatre catégories : 连接认证（
ANTHROPIC_API_KEY/BASE_URL/MODEL）、超时（API_TIMEOUT_MS默认 10 分钟）、隐私（DISABLE_TELEMETRY/DO_NOT_TRACK）、多账号（CLAUDE_CONFIG_DIR）；改完务必重启claude才生效。
05 Priorité : quand une option est définie à plusieurs endroits, qui a le dernier mot ?
À ce stade, une question évidente se pose : si le modèle peut être défini via ANTHROPIC_MODEL, sélectionné avec la commande /model et écrit dans le champ model de settings.json — quel paramètre l'emporte si les three sont configurés ?
C'est ici qu'intervient la règle de priorité (precedence). Si vous ne la comprenez pas, vous risquez de vous demander pourquoi une option que vous pensez avoir configurée n'est pas appliquée.
Retenez d'abord la règle générale officielle — les variables d'environnement l'emportent sur les champs de configuration :
当相同的行为同时具有环境变量和设置字段时，环境变量优先。例如，
ANTHROPIC_MODEL覆盖model设置。当环境变量未设置时，设置字段适用。
Analogie : la parole directe du patron prévaut sur le manuel de l'employé. Le manuel de l'employé (le champ dans settings.json) stipule noir sur blanc « remboursement de taxi limité à 50 € » ; mais aujourd'hui, le patron vous dit directement « ce déplacement est lointain, fais-toi rembourser au réel » (la variable d'environnement). Pour ce trajet, vous suivez évidemment la consigne directe du patron. La variable d'environnement est cette « consigne directe », prioritaire sur le champ figé dans le manuel. En l'absence de consigne spécifique (si la variable n'est pas définie), vous appliquez le manuel (le champ de configuration).
Cependant, il existe une exception contre-intuitive où les débutants se font souvent piéger : les variables d'environnement ne l'emportent pas sur tout. La documentation mentionne explicitement le cas du modèle :
--model和/model覆盖ANTHROPIC_MODEL。
Autrement dit, la chaîne de priorité pour le modèle is la suivante :
/model 命令 / --model 标志 ← 最优先（你当场的选择）
↓ 盖过
ANTHROPIC_MODEL 环境变量 ← 其次
↓ 盖过
settings.json 的 model 字段 ← 兜底Pourquoi cette inversion pour le modèle ? C'est en fait très logique : changer manuellement de modèle en cours de session avec /model exprime une intention immédiate et explicite (« je veux utiliser ce modèle maintenant »), qui doit naturellement l'emporter sur la variable d'environnement figée précédemment. Cela répond à la même logique : plus une instruction est immédiate et explicite, plus sa priorité est élevée.
| Mode de configuration | Priorité relative | En résumé |
|---|---|---|
Commande /model / Option --model | Maximale | Votre choix explicite en cours de session ou au lancement |
Variable ANTHROPIC_MODEL | Moyenne | Votre valeur par défaut prédéfinie |
Champ model de settings.json | Par défaut (fallback) | Utilisé uniquement si rien d'autre n'est défini |
Attention : cette règle (« la commande/l'option l'emporte sur la variable ») est spécifique à la configuration du modèle et ne s'applique pas universellement. La documentation officielle rappelle que les interactions diffèrent selon les fonctionnalités — par exemple,
CLAUDE_CODE_EFFORT_LEVELécrasera au contraire la commande/effort. En cas de doute sur une variable spécifique, référez-vous à sa description dans le tableau officiel des variables plutôt que de faire des suppositions.
C'est une erreur classique : avoir défini ANTHROPIC_MODEL dans settings.json, puis changer de modèle avec /model au cours d'une session et l'oublier. On continue à utiliser le modèle temporaire pour le reste de la session en se demandant pourquoi le comportement diffère de la configuration. La logique is pourtant simple : le choix fait avec /model doit prévaloir sur la variable d'environnement par défaut. Ce n'est pas un bug, c'est un comportement voulu.
💡 Résumé en une phrase : La règle générale est Variable d'environnement > Champ de configuration ; le modèle fait exception car la commande
/model或--model这种「当场明确指令」反过来压过ANTHROPIC_MODEL；规律是「越当场越明确，优先级越高」，拿不准就查官方那行说明。
06 Pratique : configurer une variable et vérifier qu'elle est bien active
La théorie ne remplace pas la pratique. Voici un exercice simple et complet pour vous approprier le concept : configurer une variable → lancer une session → vérifier son activation. Cela ne prend que quelques minutes et ne nécessite aucune configuration complexe existante.
Nous allons utiliser BASH_DEFAULT_TIMEOUT_MS (délai d'expiration par défaut des commandes bash). Nous avons choisi cette variable car elle est sûre, easy à observer, et une erreur de saisie ne bloquera pas vos connexions.
Étape 1 : Vérifier l'état par défaut (dans le terminal, avant de lancer claude)
Sans rien configurer, ouvrez directement une session :
claudeUne fois dans la session, posez-lui la question suivante concernant le délai d'expiration bash :
我现在的 bash 命令默认超时是多少毫秒?读一下你环境里的 BASH_DEFAULT_TIMEOUT_MS,没设的话就说默认值Résultat attendu : Claude vous indiquera que la variable n'est pas définie explicitement et qu'elle utilise la valeur par défaut de 120000 (2 minutes). Notez cette valeur de référence pour comparer plus tard. Quittez ensuite la session (en tapant /exit ou en appuyant deux fois sur Ctrl+C).
Étape 2 : Définir temporairement une valeur dans le shell et relancer la session
De retour dans le terminal, définissez temporairement une autre valeur (par exemple, 5 minutes) with export, puis lancez la session :
export BASH_DEFAULT_TIMEOUT_MS="300000"
claudeSur Windows PowerShell, utilisez :
$env:BASH_DEFAULT_TIMEOUT_MS = "300000"然后claude。
Une fois connecté, posez la même question :
我现在的 bash 命令默认超时是多少毫秒?Résultat attendu : Cette fois, Claude doit lire la valeur 300000 (5 minutes) au lieu du réglage par défaut de 120000. Le passage de la valeur de 120000 à 300000 confirme que votre configuration temporaire a bien été prise en compte. Cela valide le bon fonctionnement de la « Méthode 1 : Définition temporaire dans le shell ».
Étape 3 : Vérifier que la configuration disparaît à la fermeture du terminal
Quittez la session, fermez complètement cette fenêtre de terminal, ouvrez-en une nouvelle, puis lancez directement claude (sans exécuter d'export cette fois). Posez à nouveau la même question.
Résultat attendu : La valeur est revenue à 120000 (valeur par défaut). 因为 export 只对那个已经关掉的终端有效——这就亲眼印证了第 02 节那条「shell 临时设，关掉终端就没了」。
Étape 4 (facultative) : Enregistrer dans settings.json pour rendre le paramètre persistant
Si vous souhaitez que cette valeur soit appliquée durablement et indépendamment de la méthode de lancement, écrivez-la dans settings.json. Il est plus sûr de l'ajouter dans le fichier personnel qui n'est pas suivi par git :
{
"env": {
"BASH_DEFAULT_TIMEOUT_MS": "300000"
}
}写进
.claude/settings.local.json（当前项目根、不进 git），或~/.claude/settings.json（你的主目录、所有项目通用），按你想要的范围选——参考第 03 节那张表。
Après avoir enregistré, ouvrez un nouveau terminal, lancez directement claude（不 export），再问一遍 — la valeur lue doit désormais être stable à 300000, 而且无论你以后怎么启动 claude，它都在. C'est le principal avantage de la « Méthode 3 : Écriture dans settings.json » par rapport à un export temporaire : 一次写好，不用回回 export.
En complétant ces quatre étapes, vous avez expérimenté l'ensemble du cycle de vie d'une variable d'environnement : Configuration → Validation de l'activation → Vérification de la portée → Persistance. 以后设任何变量，本质都是这套：先临时试管不管用，确认了再挪进 settings.json 固化。
💡 Résumé en une phrase : Pour vérifier si une variable est bien active, 最稳的办法就是「问 Claude 它读到的值」；先 shell 临时
export试探（关终端就没）、确认管用再写进settings.json持久化——亲手走一遍这条链路，环境变量就再也不玄了。
07 Récapitulatif
Dans cet article, nous avons exploré les coulisses pour répertorier et comprendre les « interrupteurs généraux » qui régissent les comportements de base de Claude Code : les variables d'environnement.
En résumé, nous avons abordé de nombreux points clés : leur rôle, leur emplacement de configuration, le choix du fichier cible, les variables les plus courantes et les règles de priorité en cas de doublons. Voici un tableau de synthèse :
| Concept à clarifier | Solution | Point clé |
|---|---|---|
| Rôle des variables | Comportements de base (connexion, authentification, expiration, confidentialité) | 启动时读的键值对开关，「设一次长期生效」 |
| Où les configurer | Temporairement dans le shell / ~/.zshrc / champ env de settings.json | 按生效范围选，长期用推荐 settings.json |
| Quel fichier settings choisir | Répertoire personnel / racine du projet (dans git) / .local (exclu de git) | 带凭据的别进 git |
| Variables courantes | ANTHROPIC_*, API_TIMEOUT_MS, DISABLE_TELEMETRY, CLAUDE_CONFIG_DIR | 各有默认值，改完重启才生效 |
| Priorité en cas de conflit | Variable d'environnement > Champ de config ; exception : /model l'emporte sur ANTHROPIC_MODEL | 越当场越明确，优先级越高 |
Vous êtes désormais en mesure de : comprendre ce que contrôlent les variables d'environnement dans Claude Code, distinguer la portée des trois méthodes de configuration, identifier parmi les quatre fichiers settings.json ceux qui doivent être exclus de git, utiliser les variables courantes (connexion, délais d'expiration, confidentialité, multi-comptes) et appliquer les règles de priorité en cas de doublons. De plus, vous avez configuré vous-même une variable, validé son activation et observé la différence entre un export temporaire et une configuration persistante. Les variables d'environnement n'ont plus de secret pour vous.
Comme indiqué en introduction : les variables d'environnement ne sont pas réservées aux experts, mais constituent des préréglages dont on bénéficie durablement. Les configurations répétitives que vous deviez effectuer manuellement dans les articles précédents peuvent maintenant être réglées une fois pour toutes.
Le prochain article 43 « Flux de travail Git » — Maintenant que les variables d'environnement vous permettent de stabiliser le comportement de base de Claude Code, il est temps de l'intégrer pleinement dans votre routine de développement quotidienne. En développement, Git is incontournable : confier à Claude l'écriture des messages de commit, l'analyse des diffs, la création de PR ou la résolution des conflits... Jusqu'où peut-il vous aider et quels sont les pièges à surveiller par vous-même ? Nous en parlerons en detail dans le prochain article. Posez-vous cette question : êtes-vous prêt à laisser l'IA faire un git commit à votre place, mais oseriez-vous la laisser faire un git push sur la branche de production sans vérification ?