Passer au contenu principal
Quand Claude ignore une instruction ou qu’une fonctionnalité que vous avez configurée n’apparaît pas, la cause est généralement que le fichier n’a pas été chargé, qu’il a été chargé depuis un emplacement différent de celui que vous attendiez, ou qu’un autre fichier l’a remplacé. Ce guide montre comment inspecter ce que Claude Code a réellement chargé afin que vous puissiez déterminer lequel de ces cas s’applique. Pour les problèmes d’installation, d’authentification et de connectivité, consultez plutôt Troubleshooting.

Voir ce qui a été chargé dans le contexte

La commande /context affiche tout ce qui occupe la fenêtre de contexte pour la session actuelle, ventilé par catégorie : invite système, fichiers de mémoire, skills, outils MCP et messages de conversation. Exécutez-la d’abord pour confirmer si vos fichiers CLAUDE.md, règles ou descriptions de skills sont présents. Pour plus de détails sur une catégorie spécifique, suivez avec la commande dédiée :
CommandeAffiche
/memoryQuels fichiers CLAUDE.md et règles ont été chargés, plus les entrées de mémoire automatique
/skillsLes skills disponibles provenant des sources de projet, utilisateur et plugin
/agentsLes sous-agents configurés et leurs paramètres
/hooksLes configurations de hooks actives
/mcpLes serveurs MCP connectés et leur statut
/permissionsLes règles d’autorisation et de refus résolues actuellement en vigueur
/doctorDiagnostics de configuration : clés invalides, erreurs de schéma, santé de l’installation
/statusLes sources de paramètres actives, y compris si les paramètres gérés sont en vigueur
Si un fichier de mémoire est absent de /memory, vérifiez son emplacement par rapport à comment les fichiers CLAUDE.md se chargent. Les fichiers CLAUDE.md des sous-répertoires se chargent à la demande quand Claude lit un fichier dans ce répertoire avec l’outil Read, pas au démarrage de la session. Si /memory confirme que le fichier a été chargé mais que Claude ne suit toujours pas une instruction particulière, le problème est probablement la façon dont l’instruction est écrite plutôt que si elle a été chargée. CLAUDE.md fonctionne bien pour le type de conseils que vous donneriez à un nouveau coéquipier, comme les conventions de projet, les commandes de compilation et l’emplacement des fichiers. L’adhérence diminue quand une instruction est assez vague pour être interprétée de plusieurs façons, quand deux fichiers donnent des directives conflictuelles, ou quand le fichier est devenu assez long pour que les règles individuelles reçoivent moins d’attention. Écrire des instructions efficaces couvre les modèles de spécificité, de taille et de structure qui maintiennent l’adhérence élevée.
CLAUDE.md et les permissions résolvent des problèmes différents. CLAUDE.md dit à Claude comment fonctionne votre projet afin qu’il prenne de bonnes décisions. Permissions et hooks appliquent des limites indépendamment de ce que Claude décide. Utilisez CLAUDE.md pour « nous le faisons de cette façon ici ». Utilisez les permissions ou les hooks pour les limites de sécurité et tout ce qui ne doit jamais se produire, où vous avez besoin d’une garantie plutôt que de conseils.

Vérifier les paramètres résolus

Les paramètres fusionnent entre les portées gérées, utilisateur, projet et locale. Les paramètres gérés gagnent toujours quand ils sont présents. Parmi le reste, la portée plus proche remplace la plus large dans l’ordre local, puis projet, puis utilisateur. Certains paramètres peuvent également être définis par des drapeaux de ligne de commande ou des variables d’environnement, qui agissent comme une autre couche de remplacement. Quand un paramètre ne semble pas s’appliquer, la valeur que vous avez définie est généralement remplacée par une autre portée ou une variable d’environnement. Exécutez /doctor pour valider vos fichiers de configuration et mettre en évidence les clés invalides ou les erreurs de schéma. Exécutez /status pour voir quelles sources de paramètres sont actives, y compris si les paramètres gérés sont en vigueur. Pour comprendre quelle portée gagne pour une clé donnée, consultez Comment les portées interagissent.

Vérifier les serveurs MCP

Exécutez /mcp pour voir chaque serveur configuré, son statut de connexion et si vous l’avez approuvé pour le projet actuel. Un serveur peut être défini correctement mais ne pas fournir d’outils pour quelques raisons courantes :
  • Les serveurs à portée de projet dans .mcp.json nécessitent une approbation unique. Si l’invite a été rejetée, le serveur reste désactivé jusqu’à ce que vous l’approuviez depuis /mcp.
  • Un serveur qui échoue au démarrage s’affiche comme échoué dans /mcp. Les chemins de fichiers relatifs dans command ou args sont une cause fréquente, car ils se résolvent par rapport au répertoire à partir duquel vous avez lancé Claude Code plutôt qu’à l’emplacement de .mcp.json.
  • Un serveur qui s’affiche comme connecté mais qui liste zéro outils a démarré avec succès mais ne retourne pas de liste d’outils. Sélectionnez Reconnect depuis /mcp. Si le nombre reste à zéro, exécutez claude --debug mcp pour voir la sortie stderr du serveur.
Pour les emplacements de configuration et les règles de portée, consultez MCP.

Vérifier les hooks

Exécutez /hooks pour lister chaque hook enregistré pour la session actuelle, groupé par événement. Si un hook que vous avez défini n’apparaît pas, il n’est pas en cours de lecture : les hooks vont sous la clé "hooks" dans un fichier de paramètres, pas dans un fichier autonome. Si le hook apparaît mais ne se déclenche pas, le matcher est la cause habituelle. Le champ matcher est une chaîne unique qui utilise | pour correspondre à plusieurs noms d’outils, par exemple "Edit|Write". Un nom d’outil mal orthographié échoue silencieusement car le matcher ne correspond jamais. Une valeur de tableau est une erreur de schéma : Claude Code affiche un avis d’erreur de paramètres, /doctor signale l’échec de validation et l’entrée du hook est supprimée afin qu’elle n’apparaisse pas dans /hooks. Les modifications apportées à settings.json prennent effet dans la session en cours après un bref délai de stabilité du fichier. Vous n’avez pas besoin de redémarrer. Si /hooks affiche toujours l’ancienne définition quelques secondes après l’enregistrement, exécutez /hooks à nouveau pour actualiser la vue. Si /hooks affiche le hook mais qu’il ne se déclenche toujours pas, l’étape suivante consiste à regarder l’évaluation du hook en direct. Démarrez une session avec claude --debug hooks et déclenchez l’appel d’outil. Le journal de débogage enregistre chaque événement, quels matchers ont été vérifiés et le code de sortie et la sortie du hook. Consultez Debug hooks pour le format du journal et hooks troubleshooting pour les modèles d’échec courants.

Causes courantes

La plupart des surprises de configuration remontent à un petit ensemble de règles d’emplacement et de syntaxe. Vérifiez-les avant de supposer un bogue :
SymptômeCauseCorrection
Le hook ne se déclenche jamaismatcher est un tableau JSON au lieu d’une chaîneUtilisez une chaîne unique avec | pour correspondre à plusieurs outils, par exemple "Edit|Write". Consultez matcher patterns.
Le hook ne se déclenche jamaisLa valeur matcher est en minuscules, par exemple "bash"La correspondance est sensible à la casse. Les noms d’outils sont en majuscules : Bash, Edit, Write, Read.
Le hook ne se déclenche jamaisLes hooks sont dans un fichier .claude/hooks.json autonomeIl n’y a pas de fichier hooks autonome. Définissez les hooks sous la clé "hooks" dans settings.json. Consultez hook configuration.
Les permissions, hooks ou env définis globalement sont ignorésLa configuration a été ajoutée à ~/.claude.json~/.claude.json contient l’état de l’application et les bascules d’interface utilisateur. permissions, hooks et env appartiennent à ~/.claude/settings.json. Ce sont deux fichiers différents.
Une valeur settings.json semble ignoréeLa même clé est définie dans settings.local.jsonsettings.local.json remplace settings.json, et les deux remplacent ~/.claude/settings.json. Consultez settings precedence.
Le skill n’apparaît pas dans /skillsLe fichier skill est à .claude/skills/name.md au lieu d’être dans un dossierUtilisez un dossier avec SKILL.md à l’intérieur : .claude/skills/name/SKILL.md.
Le skill apparaît dans /skills mais Claude ne l’invoque jamaisLe skill a disable-model-invocation: true dans son frontmatter, ou sa description ne correspond pas à la façon dont vous formulez la demandeVérifiez le badge dans /skills : un label « user-only » signifie que Claude ne le déclenchera pas de lui-même. Consultez skill invocation.
Les instructions du sous-répertoire CLAUDE.md semblent ignoréesLes fichiers du sous-répertoire se chargent à la demande, pas au démarrage de la sessionIls se chargent quand Claude lit un fichier dans ce répertoire avec l’outil Read, pas au lancement et pas lors de l’écriture ou de la création de fichiers là-bas. Consultez how CLAUDE.md files load.
Le sous-agent ignore les instructions CLAUDE.mdLes sous-agents n’héritent pas toujours de la mémoire du projetMettez les règles critiques dans le corps du fichier agent, qui devient l’invite système du sous-agent. Consultez subagent configuration.
La logique de nettoyage ne s’exécute jamais à la fin de la sessionAucun hook SessionEnd configuréSessionStart et SessionEnd existent tous les deux. Consultez la hook events list.
Les serveurs MCP dans .mcp.json ne se chargent jamaisLe fichier est sous .claude/ ou utilise le format de configuration de Claude DesktopLa configuration MCP du projet va à la racine du référentiel sous .mcp.json, pas à l’intérieur de .claude/. Consultez MCP configuration.
Le serveur MCP du projet ajouté n’apparaît pasL’invite d’approbation unique a été rejetéeLes serveurs à portée de projet nécessitent une approbation. Exécutez /mcp pour voir le statut et approuver.
Le serveur MCP échoue au démarrage depuis certains répertoirescommand ou args utilise un chemin de fichier relatifUtilisez des chemins absolus pour les scripts locaux. Les exécutables sur votre PATH comme npx ou uvx fonctionnent tels quels.
Le serveur MCP démarre sans les variables d’environnement attenduesLes variables sont dans settings.json env, qui ne se propage pas aux processus enfants MCPDéfinissez plutôt env par serveur à l’intérieur de .mcp.json.
La règle de refus Bash(rm *) ne bloque pas /bin/rm ou find -deleteLes règles de préfixe correspondent à la chaîne de commande littérale, pas à l’exécutable sous-jacentAjoutez des modèles explicites pour chaque variante, ou utilisez un PreToolUse hook ou le sandbox pour une garantie difficile.

Ressources connexes

Pour la référence complète sur chaque surface de configuration, consultez la page dédiée :