Claude Code peut charger simultanément des instructions provenant de plusieurs emplacements. Si vous gérez deux projets clients, une nouvelle session dans chaque dossier permet de vérifier quels fichiers d’instructions sont réellement entrés dans chaque contexte. Le résultat utile est une paire de listes enregistrées, pas l’hypothèse que des dossiers voisins séparent les informations des clients.
Le grand changement
Ce qui change : Ce guide transforme la hiérarchie documentée des instructions Claude Code en une comparaison reproductible entre deux dossiers de projet existants et autorisés. Vous relevez les fichiers chargés au lancement, puis vérifiez si un fichier d’instructions imbriqué apparaît après une lecture permise.
Pourquoi c’est important : Un parent commun, une instruction personnelle, un import, une règle ou un réglage peuvent affecter les deux projets. /context indique quels fichiers mémoire sont chargés dans la session en cours ; vous pouvez donc examiner un chemin inattendu avant de travailler pour le client.
À surveiller : Les instructions chargées ne limitent pas les fichiers accessibles à Claude et ne garantissent pas leur respect. Examinez le compte réel, les permissions, imports, hooks et conditions d’utilisation des données avant d’envoyer du contenu client au fournisseur choisi.
Ce qu’il vous faut
Cette procédure s’adresse à un développeur autorisé à examiner deux dépôts clients existants et leur configuration Claude Code. Obtenez une autorisation distincte pour envoyer le contenu précis envisagé au compte Claude ou au fournisseur choisi. Le seul droit de modifier des fichiers locaux ne règle pas cette question. Il faut un terminal, Claude Code installé, un compte ou fournisseur admissible et un fichier existant sans données sensibles dans un sous-dossier de l’un des projets. Consultez la documentation Anthropic sur l’installation, les coûts et l’utilisation des données pour votre mode d’accès.
L’arborescence ci-dessous indique les chemins à identifier ; elle ne demande pas de créer de nouveaux projets clients. Remplacez chaque chemin illustratif des commandes par un chemin réel et autorisé. Un fichier parent CLAUDE.md est facultatif et ne doit contenir que des instructions approuvées pour les deux projets. Le fichier imbriqué et le document sans données sensibles doivent déjà convenir au circuit de données du compte choisi.
AUTHORIZED_PARENT/
CLAUDE.md optional shared instructions
project-A/
CLAUDE.md A's project instructions
project-B/
CLAUDE.md B's project instructions
subdir/
CLAUDE.md B's nested instructions
README.md authorized, nonsensitive read target1. Résoudre les deux chemins de projet
Utilisez au choix PowerShell ou Bash. Affectez aux variables les deux dossiers réels. Les vérifications exigent des chemins existants, comparent les chaînes obtenues et confirment l’existence de la cible de lecture dans B. La commande PowerShell Resolve-Path peut conserver un alias de lien symbolique ou de jonction ; deux chaînes différentes ne prouvent pas que les projets physiques sont distincts. Examinez les liens et jonctions des deux chemins de lancement et de leurs ancêtres, suivez leurs cibles et confirmez que A et B sont réellement distincts avant de continuer. Gardez les chemins, vérifications de cibles et listes de contexte dans un relevé privé.
$a = (Resolve-Path -LiteralPath 'C:\actual\authorized\project-A' -ErrorAction Stop).Path
$b = (Resolve-Path -LiteralPath 'C:\actual\authorized\project-B' -ErrorAction Stop).Path
if (-not (Test-Path -LiteralPath $a -PathType Container)) { throw 'A must be an existing directory' }
if (-not (Test-Path -LiteralPath $b -PathType Container)) { throw 'B must be an existing directory' }
if ($a -eq $b) { throw 'A and B must be different directories' }
$target = Join-Path $b 'subdir/README.md'
if (-not (Test-Path -LiteralPath $target -PathType Leaf)) { throw 'Choose an existing authorized nonsensitive file in B/subdir' }
$a
$b
$targeta=$(realpath -- /actual/authorized/project-A) || exit 1
b=$(realpath -- /actual/authorized/project-B) || exit 1
test -d "$a" || { printf '%s\n' 'A must be an existing directory' >&2; exit 1; }
test -d "$b" || { printf '%s\n' 'B must be an existing directory' >&2; exit 1; }
test "$a" != "$b" || { printf '%s\n' 'A and B must be different directories' >&2; exit 1; }
target="$b/subdir/README.md"
test -f "$target" || { printf '%s\n' 'Choose an existing authorized nonsensitive file in B/subdir' >&2; exit 1; }
printf '%s\n' "$a" "$b" "$target"Si les projets ne sont pas voisins, relevez leurs chaînes d’ancêtres séparément. Ne déduisez pas un parent commun du dessin.
2. Auditer les sources possibles avant d’ouvrir les projets
Pour chaque dossier de lancement résolu, examinez CLAUDE.md, .claude/CLAUDE.md, CLAUDE.local.md, AGENTS.md et .claude/AGENTS.md dans ce dossier et tous ses ancêtres jusqu’à la racine du système de fichiers. Examinez aussi les instructions administrées de votre système, ~/.claude/CLAUDE.md, les règles utilisateur et les fichiers .claude/rules/ du projet. Le manuel de la mémoire explique que les fichiers CLAUDE.md découverts s’additionnent ; un fichier plus proche n’efface pas le texte d’un ancêtre. Un fichier imbriqué CLAUDE.md est normalement chargé après que Claude lit, écrit ou modifie un autre fichier du même dossier. Les règles limitées à un chemin peuvent être chargées lors de l’accès à un fichier correspondant.
Ces commandes ne listent que des chemins et donnent l’inventaire des ancêtres sans afficher le contenu des fichiers. Examinez les fichiers trouvés avec l’autorité de leur propriétaire. Répétez avec les deux variables ; dans Bash, la boucle couvre automatiquement les deux.
foreach ($start in @($a, $b)) {
$dir = [System.IO.DirectoryInfo]::new($start)
while ($null -ne $dir) {
Get-Item -LiteralPath $dir.FullName -Force | Select-Object FullName,LinkType,Target
foreach ($name in @('CLAUDE.md', 'CLAUDE.local.md', 'AGENTS.md', '.claude/CLAUDE.md', '.claude/AGENTS.md')) {
$candidate = Join-Path $dir.FullName $name
if (Test-Path -LiteralPath $candidate -PathType Leaf) { $candidate }
}
$dir = $dir.Parent
}
}for start in "$a" "$b"; do
dir=$start
while :; do
for name in CLAUDE.md CLAUDE.local.md AGENTS.md .claude/CLAUDE.md .claude/AGENTS.md; do
test -f "$dir/$name" && printf '%s\n' "$dir/$name"
done
test "$dir" = / && break
dir=$(dirname -- "$dir")
done
doneLisez les fichiers d’instructions réels et leurs imports @path ; les imports relatifs sont résolus depuis le fichier qui les contient. Suivez tout lien symbolique ou jonction de chaque chemin de lancement PowerShell et de ses ancêtres, puis auditez les hiérarchies nommées et cibles qui peuvent affecter la session. Vérifiez les cibles des liens de fichiers d’instructions et les motifs claudeMdExcludes . Examinez .claude/settings.json, .claude/settings.local.json, les réglages utilisateur et administrés, les options de lancement --settings ou --setting-sources , les hooks configurés et l’état de confiance de chaque projet. CLAUDE_CONFIG_DIR peut déplacer le dossier de configuration utilisateur ; vérifiez-le avant de supposer ~/.claude. Examinez les commandes possibles des hooks avant d’accepter la confiance dans l’espace de travail. Un import hors du dossier de travail peut demander une approbation ; un import refusé n’apparaîtra pas comme prévu. Le manuel des réglages explique quelle couche fournit chaque réglage et quels réglages de projet attendent la confiance.
Vérifiez le choix Project instructions dans /config ou son réglage de plugin utilisateur/administré. La documentation actuelle de Claude Code décrit AGENTS.md comme une solution de repli conditionnelle lorsqu’aucun fichier de projet ou ancêtre CLAUDE.md ou CLAUDE.local.md ne remplit les conditions ; claude-md-and-agents-md charge les deux. La prise en charge directe de AGENTS.md dépend de la version et du plugin activé. Des versions antérieures et certains réglages pouvaient l’omettre, notamment le problème de version traité dans notre article sur le drapeau de fonctionnalité AGENTS.md. Utilisez votre version réelle, le réglage et le résultat /context plutôt que de supposer un chargement systématique.
Notez les arguments --add-dir et CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD séparément. --add-dir élargit l’accès aux fichiers ; par défaut, il ne charge pas le fichier CLAUDE.md du dossier ajouté. Le commutateur d’environnement active ce chargement. Vérifiez la mémoire automatique avec /memory comme canal distinct : elle peut être partagée entre les worktrees et sous-dossiers d’un même dépôt, et son emplacement peut être remplacé. Examinez son emplacement réel et son contenu avant d’interpréter la comparaison. Ne mettez jamais d’identifiants secrets ou de faits clients non publiés dans des exemples d’instructions ou dans un relevé public.
Avant le lancement, vérifiez ces variables d’environnement dans le shell utilisé. Une valeur Bash vide signifie absente ou vide ; PowerShell ne liste que les variables présentes. Ces valeurs n’excluent pas des valeurs dans les fichiers de réglages : confirmez les réglages actifs dans chaque session.
Get-Item Env:CLAUDE_CONFIG_DIR,Env:CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD -ErrorAction SilentlyContinue | Select-Object Name,Valueprintf 'CLAUDE_CONFIG_DIR=%s\n' "${CLAUDE_CONFIG_DIR-}"
printf 'CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=%s\n' "${CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD-}"3. Démarrer une nouvelle session dans le projet A
Notez claude --version et la commande de lancement exacte. Lancez un nouveau processus depuis A, sans --resume ni --continue. N’acceptez la confiance qu’après l’audit des réglages et hooks. Exécutez /context avant de demander à Claude d’ouvrir B ou un fichier imbriqué. Notez les chemins exacts des fichiers mémoire et règles ; utilisez cette liste pour vérifier leur présence, pas pour déduire leur ordre d’injection. Utilisez /memory pour examiner les entrées personnelles, de projet et de mémoire automatique affichées ainsi que leur emplacement. Quittez ensuite la session.
claude --version
Set-Location -LiteralPath $a -ErrorAction Stop
claudeclaude --version
cd -- "$a" && claudeDans Claude Code, /status identifie les sources actives des réglages, et /permissions affiche les règles d’outils actuelles et leurs sources. Notez-les avec la liste d’instructions :
/context
/memory
/status
/permissions
/exitLes instructions applicables de A et des ancêtres communs devraient apparaître, sous réserve des réglages et exclusions audités. Un fichier propre à B ne devrait pas appartenir à la hiérarchie de lancement de A. S’il apparaît par un import, lien, dossier ajouté ou autre canal, notez ce mécanisme. Son absence ne prouve pas que les fichiers de B sont inaccessibles.
4. Ouvrir une session distincte dans B, puis lire un fichier imbriqué
Utilisez un nouveau processus Claude Code dans B avec la même version installée et le même accès compte/fournisseur. Relevez /context et /memory avant toute lecture imbriquée. Demandez à Claude de lire uniquement le fichier exact, autorisé et sans données sensibles. Confirmez dans la session que la lecture a eu lieu, puis exécutez /context à nouveau et comparez les chemins présents. La règle de chargement du manuel prévoit que le fichier de B subdir/CLAUDE.md rejoint le contexte après que Claude accède à un autre fichier du même dossier, sauf si un réglage, une exclusion ou le comportement d’une version modifie le résultat.
Set-Location -LiteralPath $b -ErrorAction Stop
claudecd -- "$b" && claudeDans Claude Code, ne remplacez la demande de lecture que si votre cible autorisée a un autre chemin relatif :
/context
/memory
/status
/permissions
Read only subdir/README.md. Tell me whether that exact file was read; do not open other files or display its contents.
/context
/exitClaude Code peut demander une permission d’outil ou proposer une autre action. N’approuvez que la lecture exacte autorisée et confirmez que l’outil a réellement ouvert ce fichier. Une réponse affirmant l’avoir lu ne suffit pas à elle seule.
5. Comparer les listes et expliquer les différences
Conservez un tableau privé contenant les chemins résolus A et B, racines des dépôts, version Claude Code, accès compte/fournisseur, commandes de lancement, état de confiance, sources des réglages, dossiers supplémentaires, chemins d’instructions et règles, imports, emplacements de mémoire automatique et les trois listes /context observées : A au lancement, B avant lecture, B après lecture. Marquez chaque fichier attendu comme présent, absent ou inexpliqué. Ne recopiez pas d’instructions client dans un rapport public.
Si un fichier attendu manque, vérifiez d’abord le dossier de lancement et le chemin réel. Vérifiez ensuite le réglage Project instructions, le plugin/la version, claudeMdExcludes, --setting-sources, les imports et leur approbation externe, les motifs de chemins des règles, les liens symboliques et la lecture imbriquée confirmée. Si un fichier inattendu apparaît, retracez son arrivée par les ancêtres, instructions utilisateur ou administrées, imports, règles, hooks, mémoire de dossiers supplémentaires et mémoire automatique. Un ancêtre commun ou une instruction personnelle peuvent être voulus ; leur provenance et contenu déterminent leur place dans les deux projets.
Ne changez une instruction ou un réglage qu’avec l’autorisation du client concerné. Examinez la différence proposée, conservez les contraintes existantes et répétez les deux observations en sessions neuves après modification. Si un chemin reste inexpliqué ou qu’un canal ne peut être inspecté faute de permission, suspendez le travail client et demandez au propriétaire ou administrateur de résoudre cette incertitude précise.
L’exercice est terminé lorsque vous disposez des deux listes de lancement, de la liste vérifiée de B avant/après lecture imbriquée et d’une explication de chaque chemin inattendu important. Il établit la présence observée des instructions pour ces sessions. Il ne prouve ni frontière de confidentialité, ni isolement d’accès, ni obéissance garantie, ni ordre exact d’utilisation des instructions par le modèle. Pour examiner et poursuivre une conversation existante, consultez notre guide du contexte de session Claude Code.
Les frais et limites d’utilisation dépendent du forfait, de l’authentification et du fournisseur. Le guide des coûts d’Anthropic indique les conditions actuelles. Cet article repose sur la documentation : BIG CHANGE n’a examiné aucun fichier client, lancé aucune session A/B, testé aucun résultat de modèle, ni mesuré temps ou coût.
Sources et lectures complémentaires
- Anthropic, « Comment Claude mémorise votre projet » : portée des instructions, imports, chargement imbriqué,
AGENTS.md, règles, exclusions, dossiers ajoutés, mémoire automatique et/memory. Les options exactes peuvent changer selon les versions de Claude Code. - Anthropic, « Fichiers de réglages et priorité » : configuration utilisateur, de projet, locale et administrée, dont
/status, confiance et réglages des hooks. - Anthropic, « Configurer les permissions » :
/permissionsaffiche les règles d’outils actives et leurs sources ; les instructions ne font pas respecter elles-mêmes l’accès aux outils. - Anthropic, « Explorer la fenêtre de contexte » :
/contextmontre les fichiers mémoire chargés dans une session active ; leur présence affichée ne prouve pas l’ordre d’injection. - Anthropic, installation, coûts et utilisation des données : confirmez les prérequis d’installation et de compte ; lisez aussi les conditions distinctes de coût et d’utilisation des données pour votre accès.



