Skip to main content
Les sous-agents sont des assistants IA spécialisés qui gèrent des types de tâches spécifiques. Utilisez-en un lorsqu’une tâche secondaire inonderait votre conversation principale avec des résultats de recherche, des journaux ou des contenus de fichiers que vous ne référencerez plus : le sous-agent effectue ce travail dans son propre contexte et retourne uniquement le résumé. Définissez un sous-agent personnalisé lorsque vous générez constamment le même type de travailleur avec les mêmes instructions. Chaque sous-agent s’exécute dans sa propre fenêtre de contexte avec une invite système personnalisée, un accès à des outils spécifiques et des permissions indépendantes. Il envoie également ses propres requêtes, qui comptent dans les mêmes limites d’utilisation que votre conversation principale. Lorsque Claude rencontre une tâche qui correspond à la description d’un sous-agent, il délègue à ce sous-agent, qui fonctionne indépendamment et retourne les résultats. Pour voir les économies de contexte en pratique, la visualisation de la fenêtre de contexte vous guide à travers une session où un sous-agent gère la recherche dans sa propre fenêtre séparée.
Les sous-agents fonctionnent au sein d’une seule session. Pour exécuter de nombreuses sessions indépendantes en parallèle et les surveiller depuis un seul endroit, consultez les agents en arrière-plan. Pour les sessions distinctes qui se transmettent des messages, consultez la messagerie entre sessions. Pour une équipe coordonnée de sessions que Claude crée et supervise, consultez les équipes d’agents.
Les sous-agents vous aident à :
  • Préserver le contexte en gardant l’exploration et l’implémentation en dehors de votre conversation principale
  • Appliquer des contraintes en limitant les outils qu’un sous-agent peut utiliser
  • Réutiliser les configurations dans les projets avec des sous-agents au niveau utilisateur
  • Spécialiser le comportement avec des invites système ciblées pour des domaines spécifiques
  • Contrôler les coûts en acheminant les tâches vers des modèles plus rapides et moins chers comme Haiku
Claude utilise la description de chaque sous-agent pour décider quand déléguer les tâches. Lorsque vous créez un sous-agent, écrivez une description claire pour que Claude sache quand l’utiliser. Ces descriptions consomment du contexte, donc gardez-les courtes. Lorsque les descriptions combinées de vos sous-agents, à l’exception des sous-agents intégrés, dépassent 15 000 jetons, Claude Code affiche un avertissement au démarrage avec le nombre total de jetons. Réduisez les champs description de vos sous-agents et déplacez les détails dans l’invite système de chaque sous-agent, qui ne se charge que lorsque ce sous-agent s’exécute.

Sous-agents intégrés

Claude Code inclut des sous-agents intégrés que Claude utilise automatiquement lorsque c’est approprié. Chacun hérite des règles de permission de la conversation parente ; la plupart s’exécutent avec un ensemble d’outils restreint. Explore et Plan démarrent sans vos fichiers CLAUDE.md ni l’instantané du statut git afin que la recherche reste rapide et peu coûteuse. Les autres sous-agents intégrés et les sous-agents personnalisés chargent les deux, sauf si vous définissez omitClaudeMd dans la définition d’un sous-agent personnalisé pour le démarrer sans les fichiers CLAUDE.md utilisateur, projet et locaux. Pour le détail complet de ce qui parvient à un sous-agent, consultez ce qui est chargé au démarrage.
Un agent rapide, en lecture seule, optimisé pour rechercher et analyser des bases de code.
  • Modèle : le modèle de la conversation principale. Lorsque la conversation principale s’exécute sur Fable, le modèle d’Explore dépend de votre mode de connexion :
    • Avec un abonnement Claude, un compte Anthropic Console ou une passerelle LLM atteinte via ANTHROPIC_BASE_URL, Explore s’exécute sur le modèle Opus vers lequel l’alias opus est résolu.
    • Sur Amazon Bedrock, Agent Platform de Google Cloud, Microsoft Foundry, Claude Platform on AWS ou une passerelle Claude apps, Explore reste sur le modèle de la conversation principale.
  • Outils : outils en lecture seule ; Write et Edit sont refusés
  • Objectif : découverte de fichiers, recherche de code, exploration de la base de code
Un sous-agent utilisateur ou projet nommé Explore remplace le sous-agent intégré et conserve son propre champ model : définissez-en donc un avec model: haiku pour exécuter l’exploration sur un modèle moins coûteux. Pour imposer un même modèle à tous les sous-agents, Explore compris, consultez Exécuter tous les sous-agents sur un seul modèle.Claude délègue à Explore lorsqu’il doit rechercher ou comprendre une base de code sans apporter de modifications. Cela permet de garder les résultats d’exploration hors du contexte de votre conversation principale.Lorsqu’il invoque Explore, Claude spécifie un niveau de minutie : quick pour des recherches ciblées, medium pour une exploration équilibrée, ou very thorough pour une analyse exhaustive.
Les sous-agents intégrés sont enregistrés par défaut dans les sessions interactives. Pour les restreindre : Un appel d’outil Agent qui omet subagent_type échoue avec subagent_type is required lorsque la session ne dispose d’aucun sous-agent general-purpose auquel se rabattre. Au-delà de ces sous-agents intégrés, vous pouvez créer les vôtres avec des prompts personnalisés, des restrictions d’outils, des modes de permission, des hooks et des skills. Les sections suivantes montrent comment démarrer et personnaliser les sous-agents.

Démarrage rapide : créer votre premier sous-agent

Les sous-agents sont des fichiers Markdown avec du frontmatter YAML. Pour en créer un, demandez à Claude de l’écrire pour vous, ou écrivez le fichier vous-même. Cette procédure pas à pas crée un sous-agent au niveau utilisateur qui examine le code et suggère des améliorations.
1

Demander à Claude de créer le sous-agent

Dans Claude Code, décrivez le sous-agent que vous souhaitez et où l’enregistrer :
Claude écrit le fichier avec un name, une description, une liste tools, un model, et un prompt système.
2

Examiner le fichier

Ouvrez ~/.claude/agents/code-improver.md et confirmez que le frontmatter correspond à ce que vous avez demandé. Le résultat ressemble à ceci :
Parce que le fichier se trouve dans ~/.claude/agents/, le sous-agent est disponible dans chaque projet sur votre machine. Pour le limiter à un seul projet, déplacez-le vers le répertoire .claude/agents/ de ce projet. Choisir la portée du sous-agent compare les deux.
3

L'essayer

Demandez à Claude de déléguer au nouveau sous-agent :
Claude délègue à votre nouveau sous-agent, qui analyse la base de code et retourne les suggestions d’amélioration. Dans la transcription, la délégation apparaît sous la forme d’une ligne d’appel d’outil montrant le nom du sous-agent suivi d’une brève description de tâche, comme code-improver(Suggest code improvements).Si Claude ne trouve pas le nouveau sous-agent, redémarrez Claude Code et réessayez. Cela se produit uniquement lorsque ~/.claude/agents/ n’existait pas avant le démarrage de la session, car une session en cours ne détecte pas un répertoire agents nouvellement créé.
Vous avez maintenant un sous-agent que vous pouvez utiliser dans n’importe quel projet sur votre machine pour analyser les bases de code et suggérer des améliorations. Vous pouvez également écrire des fichiers de sous-agents à la main, les définir via des flags CLI, ou les distribuer via des plugins. Les sections suivantes couvrent toutes les options de configuration.
L’exécution de /agents affiche un rappel pour demander à Claude ou modifier .claude/agents/ et ~/.claude/agents/ directement. Sur Claude Code v2.1.197 et antérieur, /agents ouvre un assistant interactif avec un onglet Running qui liste les sous-agents actifs et un onglet Library pour les créer, les modifier et les supprimer.

Configurer les sous-agents

La localisation d’un fichier de sous-agent détermine qui y a accès, et son frontmatter détermine ce qu’il peut faire. Cette section couvre l’emplacement des fichiers de sous-agent et chaque champ qu’ils prennent en charge.

Choisir la portée du sous-agent

Stockez les fichiers de sous-agent dans différents emplacements selon la portée. Lorsque plusieurs sous-agents partagent le même nom, Claude Code utilise celui de l’emplacement de priorité plus élevée. Les sous-agents de projet (.claude/agents/) sont idéaux pour les sous-agents spécifiques à une base de code. Enregistrez-les dans le contrôle de version pour que votre équipe puisse les utiliser et les améliorer de manière collaborative. Les sous-agents de projet sont découverts en remontant à partir du répertoire de travail actuel, donc chaque .claude/agents/ entre celui-ci et la racine du dépôt est analysé. Lorsque plusieurs de ces répertoires imbriqués définissent le même name, Claude Code utilise la définition la plus proche du répertoire de travail. Lorsque vous ajoutez un répertoire avec --add-dir ou /add-dir, Claude Code charge également son dossier .claude/agents/, aux côtés de vos sous-agents de projet. Consultez Répertoires supplémentaires pour voir quels autres types de configuration se chargent à partir de --add-dir. Pour partager les sous-agents entre les projets sans --add-dir, utilisez ~/.claude/agents/ ou un plugin. Les sous-agents utilisateur (~/.claude/agents/) sont des sous-agents personnels disponibles dans tous vos projets. Claude Code analyse .claude/agents/ et ~/.claude/agents/ de manière récursive, vous pouvez donc organiser les définitions dans des sous-dossiers tels que agents/review/ ou agents/research/. Le chemin du sous-répertoire n’affecte pas la façon dont un sous-agent est identifié ou invoqué, car l’identité provient uniquement du champ frontmatter name. Gardez les valeurs name uniques dans toute l’arborescence : si deux fichiers dans le même répertoire .claude/agents/, y compris ses sous-dossiers, déclarent le même nom, Claude Code en charge un seul, choisi par l’ordre de lecture du système de fichiers plutôt que par une priorité documentée. Entre les répertoires de projet imbriqués, la définition la plus proche du répertoire de travail l’emporte, comme décrit ci-dessus. La vérification de configuration /doctor signale les fichiers dans le même répertoire qui partagent un nom et propose de renommer ou de supprimer tous sauf un. Les répertoires agents/ des plugins sont également analysés de manière récursive. Contrairement aux portées de projet et utilisateur, un sous-dossier à l’intérieur du répertoire agents/ d’un plugin devient partie de l’identifiant limité : un fichier à agents/review/security.md dans le plugin my-plugin s’enregistre comme my-plugin:review:security. Les sous-agents définis par CLI sont passés en JSON lors du lancement de Claude Code. Ils n’existent que pour cette session et ne sont pas enregistrés sur le disque, ce qui les rend utiles pour les tests rapides ou les scripts d’automatisation. Vous pouvez définir plusieurs sous-agents dans un seul appel --agents :
En mode non interactif, --agents accepte également le chemin d’un fichier JSON contenant le même objet, pour les définitions trop grandes pour être passées sur la ligne de commande. Par exemple, claude -p --agents ./agents.json "Review my changes" lit les définitions de ce fichier. Dans une session interactive, Claude Code refuse un chemin de fichier. La forme de fichier nécessite Claude Code v2.1.281 ou ultérieur. Chaque clé de niveau supérieur dans le JSON est le nom d’un agent, et sa valeur est la définition de cet agent. Ne commencez pas un nom par -. Une définition prend ces champs :
  • prompt : le prompt système de l’agent, équivalent au corps markdown dans les sous-agents basés sur fichier. prompt peut être vide. Si vous sélectionnez un agent avec un prompt vide et aucun champ memory comme agent de la session avec --agent, le prompt système de la session reste inchangé. Un prompt vide nécessite Claude Code v2.1.281 ou ultérieur.
  • Champs de frontmatter : description, tools, disallowedTools, model, permissionMode, mcpServers, hooks, maxTurns, autoCompactWindow, skills, initialPrompt, memory, effort, background, omitClaudeMd et isolation.
  • Champs ignorés : color et experimental ne sont pas acceptés ici et sont ignorés plutôt que rejetés.
Pour savoir ce que Claude Code fait avec une valeur qu’il ne peut pas charger, et les flags et variables d’environnement qui ignorent cette vérification, consultez Invalid --agents configuration. Les sous-agents gérés sont déployés par les administrateurs de l’organisation. Placez les fichiers markdown dans .claude/agents/ à l’intérieur du répertoire des paramètres gérés, en utilisant le même format de frontmatter que les sous-agents de projet et utilisateur. Les définitions gérées ont priorité sur les sous-agents de projet et utilisateur portant le même nom. Les sous-agents de plugin proviennent des plugins que vous avez installés. Ils se chargent automatiquement aux côtés de vos sous-agents personnalisés et apparaissent dans la saisie semi-automatique @-mention sous leur nom limité. Consultez la référence des composants de plugin pour plus de détails sur la création de sous-agents de plugin.
Pour des raisons de sécurité, les sous-agents de plugin ne prennent pas en charge les champs frontmatter hooks, mcpServers ou permissionMode. Ces champs sont ignorés lors du chargement des agents à partir d’un plugin. Si vous en avez besoin, copiez le fichier d’agent dans .claude/agents/ ou ~/.claude/agents/. Vous pouvez également ajouter des règles à permissions.allow dans settings.json ou settings.local.json, mais ces règles s’appliquent à l’ensemble de la session, pas seulement au sous-agent du plugin.Si vous êtes l’auteur du plugin, fournissez plutôt les hooks dans le fichier hooks/hooks.json du plugin et les serveurs MCP dans son .mcp.json. Ils s’appliquent dès que le plugin est activé, et pas seulement à l’intérieur du sous-agent.
Vous pouvez également réutiliser une définition de sous-agent comme coéquipier d’une équipe d’agents : nommez le type de sous-agent lorsque vous demandez à Claude de lancer le coéquipier, et Claude Code lui applique des parties de cette définition. Utiliser les définitions de sous-agent pour les coéquipiers indique quelles portées et quelles parties s’appliquent dans chaque mode d’affichage.

Écrire des fichiers de sous-agent

Les fichiers de sous-agent utilisent du frontmatter YAML pour la configuration, suivi du prompt système en Markdown :
Claude Code surveille ~/.claude/agents/ et .claude/agents/. Lorsque vous ajoutez ou modifiez un fichier de sous-agent sur le disque, ou demandez à Claude d’en écrire un pour vous, Claude Code détecte le changement en quelques secondes et la prochaine délégation utilise la définition mise à jour, sans redémarrage nécessaire.Trois cas nécessitent toujours un redémarrage :
  • L’observateur couvre uniquement les répertoires qui existaient au démarrage de la session, donc après la création du premier fichier d’agent d’une portée dans un nouveau répertoire agents, redémarrez pour le charger.
  • Claude Code ne surveille pas .claude/agents/ à l’intérieur des répertoires ajoutés avec --add-dir ou /add-dir, donc après l’ajout ou la modification d’un sous-agent là-bas, redémarrez pour charger la modification.
  • Les sessions démarrées avec --disable-slash-commands ne surveillent pas du tout ces répertoires.
.claude/agents/code-reviewer.md
Le frontmatter définit les métadonnées et la configuration du sous-agent. Le corps devient le prompt système qui guide le comportement du sous-agent. Les sous-agents reçoivent uniquement ce prompt système plus les détails d’environnement de base comme le répertoire de travail, pas le prompt système de Claude Code. En mode non interactif, passez --append-subagent-system-prompt pour ajouter votre texte à la fin du prompt système de chaque sous-agent, y compris les sous-agents imbriqués, à l’exception d’un sous-agent forké, qui réutilise le prompt de la conversation. Nécessite Claude Code v2.1.205 ou ultérieur. Si votre texte est trop long pour être passé sur la ligne de commande, enregistrez-le dans un fichier et passez le chemin avec --append-subagent-system-prompt-file à la place. Le flag de fichier nécessite Claude Code v2.1.261 ou ultérieur. Un sous-agent démarre dans le répertoire de travail actuel de la conversation principale. Au sein d’un sous-agent, les commandes cd ne persistent pas entre les appels d’outils Bash ou PowerShell et n’affectent pas le répertoire de travail de la conversation principale. Pour donner au sous-agent une copie isolée du dépôt à la place, définissez isolation: worktree. Un sous-agent avec isolation: worktree exécute ses commandes Bash et PowerShell à l’intérieur de son worktree. Une commande dont le répertoire de travail se résout à votre extraction principale à la place, par exemple parce que le répertoire worktree a été supprimé pendant que le sous-agent s’exécutait, échoue avec une erreur. Cette vérification du répertoire de travail couvre l’ensemble du dépôt contenant le répertoire à partir duquel vous avez lancé Claude Code. Lorsque votre session s’exécute dans son propre worktree lié, la vérification couvre également l’extraction principale à partir de laquelle ce worktree est lié. Pour les commandes Bash, Claude Code vérifie également la commande elle-même de deux façons :
  • Il bloque une commande qui redirige git vers l’extraction principale.
  • Il refuse une commande lorsqu’il ne peut pas vérifier à partir du texte de la commande que tout git que la commande exécute reste à l’intérieur du worktree, par exemple lorsque le nom de la commande est calculé à l’exécution.
Les vecteurs de redirection et les règles de forme sont listés sous Comment Claude Code applique l’isolation. Les commandes PowerShell ne reçoivent que la vérification du répertoire de travail. Les commandes Monitor passent par les mêmes vérifications du répertoire de travail et du contenu de la commande que les commandes Bash. Lorsque la conversation principale elle-même s’exécute isolée dans un worktree, Claude Code applique les mêmes vérifications à la session et à chaque sous-agent qu’il génère, y compris les sous-agents sans isolation: worktree ; consultez Comment Claude Code applique l’isolation.

Référence de frontmatter

Configurez un sous-agent avec du frontmatter YAML entre les marqueurs --- en haut de son fichier, et écrivez son prompt système en Markdown après le --- de fermeture. Seuls name et description sont obligatoires. Les noms de champs multi-mots utilisent camelCase, tels que maxTurns et disallowedTools, et doivent correspondre exactement au tableau : Claude Code ignore un champ qu’il ne reconnaît pas sans signaler une erreur.
  • Pour trouver un champ mal orthographié dans un sous-agent qui s’est chargé, exécutez claude --debug dans votre shell et recherchez does not recognize or apply dans le journal de débogage à ~/.claude/debug/<session-id>.txt. Le journal de débogage nomme jusqu’à cinq champs de niveau supérieur du fichier du sous-agent que Claude Code ne reconnaît pas, avec le nom probablement voulu lorsqu’un champ pris en charge est proche. Nécessite Claude Code v2.1.296 ou ultérieur.
  • Pour savoir pourquoi un fichier de sous-agent ne s’est pas chargé, consultez Fichiers de sous-agent que Claude Code ignore.
Écrivez cacheTtl à l’intérieur de la carte experimental, pas au niveau supérieur du frontmatter.

Fichiers de sous-agent que Claude Code ignore

Claude Code ignore un fichier dans un répertoire agents de projet, utilisateur ou géré, ou dans un répertoire que vous ajoutez avec --add-dir, sans le signaler dans la session, lorsque le frontmatter a l’un de ces problèmes :
  • Pas de name : Claude Code traite le fichier comme de la documentation conservée à côté de vos agents.
  • Un --- d’ouverture qui n’est pas la première ligne du fichier : Claude Code lit le fichier comme n’ayant pas de frontmatter et le traite comme de la documentation.
  • Un name qui commence par -, contient : ou dépasse 256 caractères : Claude Code ignore le fichier et écrit une erreur dans le journal de débogage.
  • Un name mais pas de description : Claude Code ignore le fichier et écrit la raison dans le journal de débogage.
  • YAML qui ne s’analyse pas : Claude Code ne lit aucun champ du fichier, l’ignore et écrit l’erreur d’analyse dans le journal de débogage.
Pour voir le journal de débogage, exécutez Claude Code avec --debug. Un sous-agent de plugin dont le frontmatter n’a pas de name ou ne s’analyse pas se charge toujours, sous son nom de fichier. Pour trouver les fichiers dans un répertoire agents dont le frontmatter ne s’analyse pas, exécutez claude plugin validate contre le répertoire, par exemple .claude/agents ou ~/.claude/agents. Claude Code vérifie uniquement le répertoire que vous nommez, et ne signale pas un fichier dont le frontmatter s’analyse mais n’a pas de name. Nécessite Claude Code v2.1.233 ou ultérieur.

Choisir un modèle

Le champ model contrôle quel modèle le sous-agent utilise :
  • Alias de modèle : utilisez l’un des alias disponibles : sonnet, opus, haiku ou fable
  • ID de modèle complet : utilisez un ID de modèle complet tel que claude-opus-5-5 ou claude-sonnet-5. Accepte les mêmes valeurs que le flag --model
  • inherit : utilisez le même modèle que la conversation principale
Lorsque Claude invoque un sous-agent, il peut également passer un paramètre model pour cette invocation spécifique. Claude Code résout le modèle du sous-agent dans cet ordre :
  1. Le paramètre model par invocation
  2. Le frontmatter model de la définition du sous-agent, où inherit sélectionne le modèle de la conversation principale
  3. La variable d’environnement CLAUDE_CODE_SUBAGENT_MODEL, lorsque vous la définissez sur un alias de modèle ou un ID de modèle
  4. Le modèle de la conversation principale
Si un mod installé définit un modèle dans son hook agent.spawn, Claude Code utilise ce modèle à la place du paramètre par invocation. Dans deux cas, un alias de famille tel que opus dans le paramètre par invocation ou le frontmatter se résout au modèle de la conversation principale au lieu de la version vers laquelle l’alias pointe :
  • Le modèle de la conversation principale appartient à cette famille : le sous-agent s’exécute sur le modèle exact de la conversation principale, y compris tout suffixe [1m], donc il obtient la même fenêtre de contexte étendu que la conversation principale.
  • Claude Code ne peut pas déterminer la famille du modèle de la conversation principale, sur un fournisseur autre que l’API Anthropic : cela peut se produire avec un ARN de profil d’inférence d’application sur Amazon Bedrock que Claude Code n’a pas résolu à un modèle de support. Ce cas couvre uniquement l’alias opus, et ne s’applique pas lorsque vous définissez ANTHROPIC_DEFAULT_OPUS_MODEL, puisque opus se résout alors au modèle que vous définissez.
Un alias dans CLAUDE_CODE_SUBAGENT_MODEL se résout toujours à la version vers laquelle l’alias pointe, même lorsqu’il nomme la famille de la conversation principale. Définir la variable sur inherit est identique à la laisser non définie. Définir CLAUDE_CODE_SUBAGENT_MODEL seul ne change pas le modèle sur lequel les sous-agents Explore et Plan intégrés s’exécutent. Pour le changer, consultez Exécuter chaque sous-agent sur un modèle. Avant la v2.1.251, CLAUDE_CODE_SUBAGENT_MODEL venait en premier dans cet ordre et remplaçait à la fois le paramètre par invocation et le frontmatter, y compris model: inherit. Claude Code vérifie le paramètre par invocation, le frontmatter et les valeurs de la variable d’environnement par rapport à la liste d’autorisation availableModels de votre organisation. Pour une valeur bloquée, il substitue un autre modèle :
  • Lorsque la valeur bloquée est un alias de famille tel que opus, Claude Code exécute le sous-agent sur la version la plus récente de cette famille que la liste d’autorisation permet, en suivant les mêmes règles de substitution et portée du fournisseur que /model. Avant la v2.1.222, Claude Code exécutait le sous-agent sur le modèle hérité pour un alias de famille bloqué également.
  • Pour toute autre valeur bloquée, sur les fournisseurs où cette substitution ne fonctionne pas, ou lorsque la liste d’autorisation ne permet aucune version de la famille, Claude Code exécute le sous-agent sur le modèle hérité à la place. Si vous définissez CLAUDE_CODE_SUBAGENT_MODEL, Claude Code essaie d’abord ce modèle, selon les mêmes règles.
Dans les sessions interactives, Claude Code affiche un avertissement nommant le modèle demandé et le modèle sur lequel le sous-agent s’exécute, pour l’une ou l’autre substitution. Pour vérifier sur quel modèle un sous-agent s’exécute, exécutez /tasks. Claude Code nomme le modèle sur la ligne du sous-agent, et ajoute le niveau d’effort défini pour ce sous-agent, le cas échéant. Nécessite Claude Code v2.1.242 ou ultérieur. Un paramètre model par invocation s’applique également lorsque le sous-agent est repris ou reçoit un message de suivi, donc le sous-agent reste sur ce modèle. À partir de la v2.1.198, les sous-agents héritent également de la configuration de réflexion étendue de la conversation principale : si la réflexion est activée dans votre session, elle est activée pour le sous-agent, et si elle est désactivée, elle reste désactivée. Il n’y a pas de paramètre de réflexion par sous-agent. Avant la v2.1.198, les sous-agents s’exécutaient avec la réflexion étendue désactivée indépendamment du paramètre de la conversation principale.

Exécuter chaque sous-agent sur un modèle

CLAUDE_CODE_SUBAGENT_MODEL est une valeur par défaut, donc la définition d’un sous-agent ou un modèle que Claude passe a toujours priorité sur elle. Pour appliquer un modèle à chaque sous-agent, coéquipier et agent de workflow, définissez également CLAUDE_CODE_SUBAGENT_MODEL_FORCE sur 1. Nécessite Claude Code v2.1.257 ou ultérieur.
  • Si vous définissez les deux variables, les sous-agents s’exécutent sur le modèle dans CLAUDE_CODE_SUBAGENT_MODEL.
  • Si vous définissez uniquement CLAUDE_CODE_SUBAGENT_MODEL_FORCE, les sous-agents s’exécutent sur le modèle de la conversation principale, à ceci près que le sous-agent Explore intégré s’exécute sur le modèle indiqué pour lui sous Sous-agents intégrés.
Par exemple, pour exécuter chaque sous-agent sur Haiku, définissez les deux variables dans le bloc env d’un fichier de paramètres :
Pour vérifier que le paramètre a pris effet, exécutez /tasks pendant qu’un sous-agent s’exécute. La ligne du sous-agent affiche le modèle sur lequel il s’exécute. Tandis que CLAUDE_CODE_SUBAGENT_MODEL_FORCE est activé, Claude Code ignore le champ model dans les définitions de sous-agent, et Claude ne peut pas passer un modèle lorsqu’il démarre un sous-agent. Ces sous-agents s’exécutent toujours sur le modèle de la conversation principale :

Choisir un niveau d’effort

Pour exécuter un sous-agent à son propre niveau d’effort, définissez le champ effort dans sa définition. Lorsque vous demandez à Claude d’exécuter un sous-agent qui n’est pas un fork à un niveau d’effort spécifique, il peut également passer un paramètre effort pour cette invocation. Le paramètre remplace le champ effort et reste en vigueur lorsque le sous-agent est repris. La variable d’environnement CLAUDE_CODE_EFFORT_LEVEL a priorité sur les deux. Le paramètre par invocation nécessite Claude Code v2.1.292 ou ultérieur.

Contrôler les capacités des sous-agents

Vous pouvez contrôler ce que les sous-agents peuvent faire via l’accès aux outils, les modes de permission et les règles conditionnelles.

Outils disponibles

Les sous-agents héritent des outils intégrés et des outils MCP disponibles dans la conversation principale, réduits par deux filtres : le premier supprime une courte liste d’outils de chaque sous-agent, et le second réduit l’ensemble des outils intégrés pour les sous-agents qui s’exécutent en arrière-plan, ce qui est la valeur par défaut. Sur macOS, Linux et WSL, un sous-agent peut également recevoir les outils Glob et Grep lorsque la conversation principale ne les a pas, comme décrit sous Comportement de l’outil Glob. Les forks ignorent les deux filtres et reçoivent le pool d’outils exact de la conversation principale. Le premier filtre supprime ces outils, même lorsqu’ils sont listés dans le champ tools :
  • Agent, lorsque le sous-agent est à la limite de profondeur ; dans un fork l’outil reste listé mais retourne une erreur au lieu de générer
  • AskUserQuestion
  • EndConversation, qui ne peut terminer que la conversation principale ; consultez Comportement de l’outil EndConversation
  • EnterPlanMode
  • ExitPlanMode, sauf si le permissionMode du sous-agent est plan
  • ScheduleWakeup
  • WaitForMcpServers
  • Workflow
Le second filtre s’applique aux sous-agents s’exécutant en arrière-plan. À part Agent et ExitPlanMode, qui suivent les conditions du premier filtre partout où le sous-agent s’exécute, un sous-agent en arrière-plan conserve tous les outils MCP mais uniquement ces outils intégrés : Read, Grep, Glob, LSP, Bash, PowerShell, Edit, Write, NotebookEdit, WebFetch, WebSearch, TodoWrite, Skill, ToolSearch, EnterWorktree, ExitWorktree, Monitor, TaskStop, SendMessage et Artifact, plus SubagentHandback pour un sous-agent qui rapporte via celui-ci. Claude Code supprime tous les autres outils intégrés d’un sous-agent en arrière-plan, qu’ils soient hérités ou listés dans le champ tools, donc la même définition peut se résoudre en outils différents au premier plan et en arrière-plan. La suppression ne signale aucune erreur sauf si elle laisse la liste tools se résoudre à rien. Avant la v2.1.280, les sous-agents en arrière-plan ne pouvaient pas utiliser LSP. ListAgents suit ces filtres comme n’importe quel outil intégré : un sous-agent au premier plan l’hérite dans les sessions où la messagerie entre sessions est activée, et un sous-agent en arrière-plan ne le conserve pas. Les coéquipiers dans les équipes d’agents conservent en outre les outils de tâche et les outils cron : TaskCreate, TaskGet, TaskList, TaskUpdate, CronCreate, CronDelete et CronList. Dans une session sans les outils Task, Claude Code ne fournit pas les outils de tâche aux sous-agents non plus, même lorsque le sous-agent exécute un modèle différent. Un coéquipier en processus suit votre session de la même manière, tandis qu’un coéquipier dans son propre volet divisé s’exécute en tant que processus Claude Code séparé, donc son propre modèle décide.

Restreindre les outils qu’un sous-agent peut utiliser

Pour restreindre les outils, utilisez le champ tools comme liste d’autorisation ou le champ disallowedTools comme liste de refus. Si les deux sont définis, disallowedTools est appliqué en premier, puis tools est résolu par rapport au pool restant. Un outil listé dans les deux est supprimé. Cet exemple utilise tools pour autoriser uniquement Read, Grep, Glob et Bash. Le sous-agent ne peut pas modifier les fichiers, écrire des fichiers ou utiliser des outils MCP :
Cet exemple utilise disallowedTools pour hériter du pool d’outils du sous-agent sauf Write et Edit. Le sous-agent conserve Bash, les outils MCP et le reste de son pool :
Lorsque rien dans la liste tools ne se résout en un outil, par exemple parce que chaque entrée est mal orthographiée ou nomme un outil qui n’est pas disponible pour les sous-agents, Claude Code refuse généralement de lancer le sous-agent et l’outil Agent retourne une erreur nommant les entrées non résolues ; consultez Agent would be spawned with zero tools pour le message et comment corriger chaque entrée. Les champs tools et disallowedTools acceptent également des entrées pour un serveur MCP entier : Cet exemple supprime tous les outils du serveur MCP github tout en conservant les outils d’autres serveurs et les outils intégrés dans le pool du sous-agent :
Une entrée disallowedTools avec un spécificateur, tel que Bash(git push *), supprime toujours l’outil entier du sous-agent, pas seulement les commandes correspondantes. Pour conserver Bash et bloquer des commandes spécifiques, ajoutez une règle de refus Bash telle que Bash(git push *) à permissions.deny dans vos paramètres. La règle s’applique à la conversation principale et aux sous-agents.

Restreindre les sous-agents qui peuvent être générés

Lorsqu’un agent s’exécute en tant que thread principal avec claude --agent, il peut générer des sous-agents à l’aide de l’outil Agent. Pour restreindre les types de sous-agents qu’il peut générer, utilisez la syntaxe Agent(agent_type) dans le champ tools.
Dans la version 2.1.63, l’outil Task a été renommé en Agent. Les références Task(...) existantes dans les paramètres et les définitions d’agent fonctionnent toujours comme des alias.
C’est une liste d’autorisation : seuls les sous-agents worker et researcher peuvent être générés. Si l’agent essaie de générer un autre type, la demande échoue et l’agent ne voit que les types autorisés dans son prompt. Pour bloquer des agents spécifiques tout en autorisant tous les autres, utilisez plutôt permissions.deny. Pour autoriser la génération de n’importe quel sous-agent sans restrictions, utilisez Agent sans parenthèses :
Si vous omettez complètement Agent de la liste tools, l’agent ne peut générer aucun sous-agent avec l’outil Agent. La syntaxe de liste d’autorisation Agent(agent_type) s’applique uniquement à un agent s’exécutant en tant que thread principal avec claude --agent. Dans une définition de sous-agent, lister Agent dans tools permet à ce sous-agent de générer ses propres sous-agents tant que la limite de profondeur le permet, mais toute liste de types à l’intérieur des parenthèses est ignorée.

Limiter les serveurs MCP à un sous-agent

Utilisez le champ mcpServers pour donner à un sous-agent l’accès aux serveurs MCP qui ne sont pas disponibles dans la conversation principale. Les serveurs en ligne définis ici sont connectés au démarrage du sous-agent, selon la règle de confiance pour le dossier du fichier d’agent, et déconnectés à la fin. Les références de chaîne partagent la connexion de la session parent.
Le champ mcpServers s’applique dans les deux contextes où un fichier d’agent peut s’exécuter :
  • En tant que sous-agent, généré via l’outil Agent ou une @-mention
  • En tant que session principale, lancée avec --agent ou le paramètre agent
Lorsque l’agent est la session principale, les définitions de serveur en ligne se connectent au démarrage aux côtés des serveurs de .mcp.json et des fichiers de paramètres, selon la même règle de confiance pour le dossier du fichier d’agent. Dans /mcp, un serveur distant (HTTP ou SSE) que vous avez utilisé auparavant peut afficher le statut cached à la place ; Claude Code le connecte lorsque Claude appelle pour la première fois l’un de ses outils.
Chaque entrée de la liste est soit une définition de serveur en ligne, soit une chaîne référençant un serveur MCP déjà configuré dans votre session :
Les définitions en ligne utilisent le même schéma que les entrées de serveur .mcp.json, indexées par le nom du serveur, et prennent en charge les types stdio, http, sse et ws. Pour garder un serveur MCP en dehors de la conversation principale et éviter que ses descriptions d’outils ne consomment du contexte, définissez-le en ligne ici plutôt que dans .mcp.json. Le sous-agent obtient les outils ; la conversation parent ne les obtient pas. Les restrictions MCP qui s’appliquent à la session principale couvrent également les serveurs déclarés dans le frontmatter du sous-agent : Lorsque l’une de ces options bloque un serveur, Claude Code le saute et affiche un avertissement nommant les serveurs bloqués. Les restrictions des paramètres gérés s’appliquent à chaque sous-agent indépendamment de la façon dont il est défini. --strict-mcp-config ne filtre pas les serveurs que vous transmettez en ligne via --agents ou l’option agents du SDK, car il s’agit d’une entrée explicite de l’appelant.

Confiance requise pour les serveurs MCP en ligne

Claude Code charge un serveur MCP en ligne à partir d’un fichier d’agent dans le répertoire .claude/agents/ de votre projet, ou dans le répertoire .claude/agents/ d’un répertoire --add-dir, uniquement après que vous fassiez confiance au dossier d’où provient le fichier d’agent. Avant la v2.1.238, Claude Code chargeait ces serveurs sans vérifier la confiance.
  • La confiance qui ne compte pas : la confiance d’un dossier parent, et la confiance automatique qu’une session -p ou SDK obtient pour les hooks dans les fichiers de paramètres
  • Jusqu’à ce moment : Claude Code ignore tous les serveurs en ligne dans ce fichier d’agent et écrit la clé exacte projects["<path>"].hasTrustDialogAccepted pour ~/.claude.json dans le journal de débogage
  • Répertoires --add-dir : un répertoire en dehors du dépôt de votre espace de travail de confiance a besoin de sa propre entrée de confiance, car ses fichiers .claude/agents/ n’héritent pas de la confiance de votre espace de travail
Claude Code charge deux types de serveur sans vérifier la confiance pour le dossier d’où provient le fichier d’agent :
  • Un nom qui référence un serveur que vous avez déjà configuré
  • Un serveur en ligne dans un fichier d’agent de ~/.claude/agents/, dans un que vous passez avec --agents ou l’option agents du SDK, ou dans un que les paramètres gérés fournissent

Modes de permission

Définissez permissionMode pour choisir le mode de permission dans lequel un sous-agent s’exécute. Utilisez les valeurs de configuration des modes, donc le mode Manuel est default. Si vous le laissez non défini, le sous-agent hérite du mode de permission de la conversation principale. Le mode de permission de la conversation principale décide si Claude Code utilise la valeur que vous définissez :
  • Lorsque la conversation principale est en bypassPermissions, acceptEdits ou mode auto, le sous-agent s’exécute dans ce même mode et Claude Code ignore le permissionMode que vous définissez. En mode auto, le classifieur évalue les appels d’outils du sous-agent avec les règles de blocage et d’autorisation de la conversation principale. Lorsque le sous-agent se termine, le classifieur examine également son travail et son rapport final avant que le rapport soit livré, comme Comment le mode auto gère les sous-agents le décrit.
  • Lorsque la conversation principale est en mode default, dontAsk ou plan, le sous-agent s’exécute dans le mode de permission que vous définissez. Il conserve plutôt le mode de permission de la conversation principale dans les cas suivants :
    • Vous définissez bypassPermissions. L’exception bypassPermissions nécessite Claude Code v2.1.267 ou ultérieur.
    • Vous définissez auto et le mode auto n’est pas disponible pour le sous-agent, par exemple lorsqu’un fichier de paramètres définit disableAutoMode ou que le modèle du sous-agent ne prend pas en charge le mode auto.
permissionMode accepte ces valeurs, et manual comme alias pour default :

Précharger les skills dans les sous-agents

Utilisez le champ skills pour injecter le contenu du skill dans le contexte du sous-agent au démarrage. Cela donne au sous-agent des connaissances de domaine sans qu’il ait besoin de découvrir et charger les skills pendant l’exécution.
Le contenu complet de chaque skill listé est injecté dans le contexte du sous-agent au démarrage, dans la limite des 32 premiers noms distincts de la liste. Ce champ contrôle quels skills sont préchargés, pas à quels skills le sous-agent peut accéder : sans lui, le sous-agent peut toujours découvrir et invoquer les skills de projet, utilisateur et plugin via l’outil Skill pendant l’exécution. Pour empêcher complètement un sous-agent d’invoquer des skills, omettez Skill de la liste tools ou ajoutez-le à disallowedTools. Vous ne pouvez pas précharger les skills qui définissent disable-model-invocation: true, car le préchargement puise dans le même ensemble de skills que Claude peut invoquer. Cela inclut le skill /verify fourni, que Claude ne peut pas exécuter de lui-même. Si un skill listé est manquant ou désactivé, par exemple par la politique de votre organisation, Claude Code le saute et enregistre un avertissement dans le journal de débogage.
C’est l’inverse de l’exécution d’un skill dans un sous-agent. Avec skills dans un sous-agent, le sous-agent contrôle le prompt système et charge le contenu du skill. Avec context: fork dans un skill, le contenu du skill est injecté dans l’agent que vous spécifiez. Dans les deux cas, le sous-agent démarre sans votre historique de conversation.

Activer la mémoire persistante

Le champ memory donne au sous-agent un répertoire persistant qui survit aux conversations. Le sous-agent utilise ce répertoire pour accumuler des connaissances au fil du temps, comme les modèles de base de code, les insights de débogage et les décisions architecturales.
Choisissez une portée en fonction de la largeur d’application de la mémoire : La mémoire du sous-agent fait partie de la mémoire automatique : si vous désactivez la mémoire automatique, avec le paramètre autoMemoryEnabled ou CLAUDE_CODE_DISABLE_AUTO_MEMORY, le champ memory n’a aucun effet et le sous-agent se lance sans les instructions de mémoire ou l’accès à l’outil de mémoire décrit ci-dessous. Lorsque la mémoire est activée :
  • Le prompt système du sous-agent inclut des instructions pour lire et écrire dans le répertoire de mémoire.
  • Le prompt système du sous-agent inclut également les 200 premières lignes ou 25 KB de MEMORY.md dans le répertoire de mémoire, selon la première limite atteinte, avec des instructions pour organiser MEMORY.md s’il dépasse cette limite.
  • Les outils Read, Write et Edit sont automatiquement activés pour que le sous-agent puisse gérer ses fichiers de mémoire.
  • project est la portée par défaut recommandée. Elle rend les connaissances du sous-agent partageables via le contrôle de version.
  • Demandez au sous-agent de consulter sa mémoire avant de commencer le travail : « Examinez cette PR et consultez votre mémoire pour les modèles que vous avez vus auparavant. »
  • Demandez au sous-agent de mettre à jour sa mémoire après avoir terminé une tâche : « Maintenant que vous avez terminé, enregistrez ce que vous avez appris dans votre mémoire. » Au fil du temps, cela crée une base de connaissances qui rend le sous-agent plus efficace.
  • Incluez les instructions de mémoire directement dans le fichier markdown du sous-agent pour qu’il maintienne proactivement sa propre base de connaissances :

Règles conditionnelles avec hooks

Pour un contrôle plus dynamique de l’utilisation des outils, utilisez les hooks PreToolUse pour valider les opérations avant leur exécution. C’est utile lorsque vous devez autoriser certaines opérations d’un outil tout en bloquant d’autres. Cet exemple crée un sous-agent qui n’autorise que les requêtes de base de données en lecture seule. Le hook PreToolUse exécute le script spécifié dans command avant chaque commande Bash :
Claude Code passe l’entrée du hook en JSON via stdin aux commandes du hook. Le script de validation lit ce JSON, extrait la commande Bash et quitte avec le code 2 pour bloquer les opérations d’écriture :
Sur macOS et Linux, rendez le script exécutable, sinon le hook échoue au lieu de bloquer quoi que ce soit :
Pour tester la règle, demandez au sous-agent d’exécuter une instruction UPDATE : le script quitte avec le code 2, Claude Code bloque la commande, et le sous-agent voit le message Blocked: Only SELECT queries are allowed. Consultez Entrée du hook pour le schéma d’entrée complet et codes de sortie pour savoir comment les codes de sortie affectent le comportement. Sur Windows, écrivez les scripts de hook en PowerShell et ajoutez shell: powershell à l’entrée du hook comme indiqué dans exécution de hooks en PowerShell.

Désactiver des sous-agents spécifiques

Vous pouvez empêcher Claude d’utiliser des sous-agents spécifiques en les ajoutant au tableau deny dans vos paramètres. Utilisez le format Agent(subagent-name) où subagent-name correspond au champ name du sous-agent.
Cela fonctionne pour les sous-agents intégrés et personnalisés. Vous pouvez également utiliser le flag CLI --disallowedTools :
Consultez la documentation Permissions pour plus de détails sur les règles de permission.

Définir les hooks pour les sous-agents

Les sous-agents peuvent définir des hooks qui s’exécutent pendant le cycle de vie du sous-agent. Il y a deux façons de configurer les hooks :
  • Dans le frontmatter du sous-agent : définir les hooks qui s’exécutent uniquement pendant que ce sous-agent est actif
  • Dans settings.json : définir les hooks au niveau de la session qui se déclenchent également à l’intérieur des sous-agents. Les événements d’outils tels que PreToolUse et PostToolUse se déclenchent pour les appels d’outils du sous-agent de la même manière qu’ils le font dans la conversation principale, et SubagentStart et SubagentStop se déclenchent lorsqu’un sous-agent démarre ou se termine
Les hooks des fichiers de paramètres, des paramètres de politique gérée et des plugins s’appliquent tous à l’intérieur des sous-agents, donc un hook PreToolUse dans settings.json s’exécute également avant chaque outil qu’un sous-agent utilise.

Hooks dans le frontmatter du sous-agent

Définissez les hooks directement dans le fichier markdown du sous-agent. Ces hooks s’exécutent uniquement pendant que ce sous-agent spécifique est actif et sont nettoyés à la fin.
Les hooks de frontmatter se déclenchent lorsque l’agent est généré en tant que sous-agent via l’outil Agent ou une @-mention, et lorsque l’agent s’exécute en tant que session principale via --agent ou le paramètre agent. Dans le cas de la session principale, ils s’exécutent aux côtés de tous les hooks définis dans settings.json.
Pour que les hooks de frontmatter d’un sous-agent au niveau du projet s’exécutent, acceptez la boîte de dialogue de confiance de l’espace de travail pour le dossier qui contient le fichier d’agent. Les hooks des sous-agents au niveau utilisateur dans ~/.claude/agents/ et des définitions que vous passez avec --agents s’exécutent sans cette étape. Si vous avez ajouté un dossier avec --add-dir en dehors du dépôt de votre espace de travail de confiance, faites confiance à ce dossier séparément : ses hooks .claude/agents/ n’héritent pas de la confiance de l’espace de travail. Jusqu’à ce que vous fassiez confiance au dossier, le sous-agent s’exécute toujours, mais Claude Code ignore ses hooks de frontmatter et enregistre une erreur dans le journal de débogage expliquant comment faire confiance au dossier. C’est une règle plus stricte que celle pour les hooks dans les fichiers de paramètres : faire confiance à un dossier parent ne suffit pas, et une session -p ne compte pas comme de confiance. Ce qui s’exécute avant que vous fassiez confiance à un dossier compare les deux. Avant la v2.1.218, les hooks de frontmatter pouvaient s’exécuter à partir de dossiers auxquels vous n’aviez pas fait confiance, y compris dans les sessions non interactives. Tous les événements de hook sont pris en charge. Les événements les plus courants pour les sous-agents sont : Cet exemple valide les commandes Bash avec le hook PreToolUse et exécute un linter après les modifications de fichiers avec PostToolUse :
Lorsque l’agent est invoqué en tant que sous-agent, les hooks Stop dans le frontmatter sont automatiquement convertis en événements SubagentStop.

Hooks au niveau du projet pour les événements de sous-agent

Configurez les hooks dans settings.json qui répondent aux événements du cycle de vie du sous-agent dans la session principale. Les deux événements prennent en charge les matchers pour cibler des types d’agents spécifiques par nom. La valeur du matcher est le name du frontmatter de l’agent pour les sous-agents au niveau du projet et utilisateur, ou l’identifiant limité au plugin tel que my-plugin:db-agent pour les sous-agents de plugin. Un nom limité contient un deux-points, il est donc évalué comme une expression régulière non ancrée ; ancrez-le avec ^ et $, comme dans ^my-plugin:db-agent$, pour correspondre uniquement à cet agent. Cet exemple exécute un script de configuration uniquement lorsque le sous-agent db-agent démarre, et un script de nettoyage lorsque n’importe quel sous-agent s’arrête :
Consultez Hooks pour le format de configuration complet des hooks.

Travailler avec des sous-agents

Comprendre la délégation automatique

Claude délègue automatiquement les tâches en fonction de la description de la tâche dans votre demande, du champ description dans les configurations des sous-agents, et du contexte actuel. Pour encourager une délégation proactive, incluez des phrases comme « use proactively » dans le champ description de votre sous-agent. Gardez les descriptions brèves : Claude Code affiche un avertissement au démarrage lorsque les descriptions combinées de vos sous-agents dépassent la limite de 15 000 tokens, et charge quand même tous les sous-agents. Si le sous-agent est fourni dans un plugin, vous pouvez mesurer la fiabilité avec laquelle Claude le délègue sur des prompts réalistes au lieu de vérifier un par un : claude plugin eval exécute chaque prompt avec et sans le plugin et évalue les résultats.

Invoquer les sous-agents explicitement

Lorsque la délégation automatique ne suffit pas, vous pouvez demander un sous-agent vous-même. Trois modèles escaladent d’une suggestion ponctuelle à une valeur par défaut pour toute la session :
  • Langage naturel : nommez le sous-agent dans votre prompt ; Claude décide s’il faut déléguer
  • @-mention : garantit que le sous-agent s’exécute pour une tâche
  • À l’échelle de la session : toute la session s’exécute en tant que ce sous-agent via le flag --agent ou le paramètre agent
Pour le langage naturel, il n’y a pas de syntaxe spéciale. Nommez le sous-agent et Claude délègue généralement :
@-mentionnez le sous-agent. Tapez @ et choisissez le sous-agent dans la saisie semi-automatique, de la même manière que vous @-mentionnez les fichiers. Cela garantit que ce sous-agent spécifique s’exécute plutôt que de laisser le choix à Claude :
Votre message complet va toujours à Claude, qui rédige le prompt de tâche du sous-agent en fonction de ce que vous avez demandé. La @-mention contrôle quel sous-agent Claude invoque, pas quel prompt il reçoit. Les sous-agents fournis par un plugin activé apparaissent dans la saisie semi-automatique sous leur nom délimité, comme my-plugin:code-reviewer ou my-plugin:review:security lorsque le plugin organise les agents dans des sous-dossiers. Les sous-agents en arrière-plan nommés actuellement en cours d’exécution dans la session apparaissent également dans la saisie semi-automatique, affichant leur statut à côté du nom. Vous pouvez également taper la mention manuellement sans utiliser le sélecteur : @agent-<name> pour les sous-agents locaux, ou @agent- suivi du nom délimité pour les sous-agents de plugin, par exemple @agent-my-plugin:code-reviewer. Pendant que vous tapez cette forme, la saisie semi-automatique affiche les correspondances de fichiers plutôt que les agents. La mention d’agent se résout toujours lorsque vous soumettez. Exécutez toute la session en tant que sous-agent. Passez --agent <name> pour démarrer une session où le thread principal lui-même prend les restrictions d’outils et le modèle de ce sous-agent :
À moins que le prompt de l’agent soit vide, le prompt système d’un sous-agent personnalisé remplace entièrement le prompt système par défaut de Claude Code, de la même manière que --system-prompt le fait. Les fichiers CLAUDE.md et la mémoire du projet se chargent toujours via le flux de messages normal, même lorsque la définition de l’agent définit omitClaudeMd. Si vous exécutez la session avec -p en tant qu’agent personnalisé qui a son propre prompt, elle démarre également sans l’instantané du statut git. Le nom de l’agent apparaît comme @<name> dans l’en-tête de démarrage pour que vous puissiez confirmer qu’il est actif. Cela fonctionne avec les sous-agents intégrés et personnalisés, et le choix persiste lorsque vous reprenez la session : Claude Code restaure les restrictions d’outils et le modèle de l’agent ainsi que la conversation. Si l’agent n’existe plus lorsque vous reprenez, la session continue avec les outils par défaut et affiche un avertissement nommant l’agent. Pour le prompt système dans l’un ou l’autre cas, voir Flags de prompt système dans les conversations reprises. Pour un sous-agent fourni par un plugin, vous pouvez passer uniquement le nom de l’agent et Claude Code le trouve :
Si plusieurs plugins fournissent des agents avec le même nom, passez le nom délimité pour lever l’ambiguïté :
Si le plugin place l’agent dans un sous-dossier de son répertoire agents/, incluez le sous-dossier dans le nom délimité, par exemple claude --agent my-plugin:review:security. Pour en faire la valeur par défaut pour chaque session dans un projet, définissez agent dans .claude/settings.json :
Le flag CLI remplace le paramètre si les deux sont présents.

Exécuter les sous-agents au premier plan ou en arrière-plan

Les sous-agents peuvent s’exécuter au premier plan ou en arrière-plan :
  • Sous-agents au premier plan bloquent la conversation principale jusqu’à la fin. Les demandes de permission vous sont transmises au fur et à mesure.
  • Sous-agents en arrière-plan s’exécutent simultanément pendant que vous continuez à travailler. Lorsqu’un sous-agent en arrière-plan atteint un appel d’outil qui nécessite une permission, Claude Code affiche la demande dans votre session principale et nomme le sous-agent qui demande. Approuvez pour laisser le sous-agent continuer, ou appuyez sur Échap pour refuser cet appel d’outil sans arrêter le sous-agent.

Quels sous-agents s’exécutent en arrière-plan

Sans aucune configuration, un sous-agent que Claude génère à partir de votre conversation principale démarre en arrière-plan.
  • claude -p et le SDK Agent : Claude peut attendre, de sa propre initiative ou lorsque vous le demandez.
  • Sessions de terminal interactives, VS Code et application de bureau sur votre machine : pour laisser Claude attendre un sous-agent, désactivez le mode fork, qui est activé par défaut.
Pour un skill avec context: fork, Claude Code suit les règles dans Exécuter les skills dans un sous-agent à la place, que le mode fork soit activé ou non.

Laisser Claude attendre un sous-agent

  1. Désactivez le mode fork en définissant CLAUDE_CODE_FORK_SUBAGENT sur 0, par exemple dans settings.json :
  2. Exécutez à nouveau claude depuis votre shell, ou ouvrez une nouvelle conversation VS Code.
  3. Demandez à Claude d’attendre lorsque vous avez d’abord besoin d’un résultat, par exemple « run the reviewer subagent and wait for its report ».
Pour continuer à travailler pendant que Claude attend, appuyez sur Ctrl+B dans le terminal ou cliquez sur Run in background dans VS Code. Si vous définissez la variable d’environnement CLAUDE_CODE_DISABLE_BACKGROUND_TASKS sur 1 au lieu de désactiver le mode fork, Claude attend chaque sous-agent et les tâches en arrière-plan sont désactivées, Ctrl+B compris.

Outils, permissions et résultats des sous-agents en arrière-plan

Les sous-agents en arrière-plan s’exécutent avec un ensemble d’outils intégrés plus petit que les sous-agents au premier plan, sauf pour les forks de conversation et les sous-agents au premier plan repris. Les sous-agents en arrière-plan affichent chaque demande de permission dans votre session principale. Lorsque vous répondez à l’une de ces demandes avec un choix qui dure au-delà de cet appel d’outil, comme une autorisation qui dure pour le reste de la session, Claude Code applique votre réponse à toute la session, y compris votre conversation principale. Un sous-agent en arrière-plan peut laisser une commande Bash ou PowerShell en arrière-plan s’exécuter au-delà de la fin de son tour. Lorsque cette commande se termine, Claude Code envoie une notification au sous-agent. Les résultats d’un sous-agent en arrière-plan atteignent Claude sous la forme d’une notification d’achèvement dans un tour ultérieur. Claude attend cette notification avant de signaler les résultats du sous-agent, et si vous demandez d’abord où en est l’avancement, il signale que le sous-agent est toujours en cours d’exécution.

Sous-agents terminés dans le panneau et la liste des tâches

Claude Code efface la ligne d’un sous-agent en arrière-plan du panneau des sous-agents sous la zone de saisie du prompt de deux façons, selon la façon dont le sous-agent s’est terminé :
  • Lorsqu’un sous-agent se termine avec succès, Claude Code supprime sa ligne immédiatement et, sauf en mode lecteur d’écran, affiche /tasks to see subagents dans le pied de page pendant 30 secondes. Pendant ces 30 secondes, exécutez /tasks et appuyez sur Entrée sur le sous-agent pour ouvrir sa transcription. Avant la v2.1.232, Claude Code gardait la ligne pendant 30 secondes après la fin du sous-agent, comme un échec, et n’affichait aucun indice de pied de page.
  • Lorsqu’un sous-agent échoue ou que vous l’arrêtez, Claude Code garde sa ligne pendant 30 secondes. Pour effacer la ligne plus tôt, sélectionnez-la et appuyez sur x.
Un sous-agent en arrière-plan qui se termine reste listé dans /tasks, marqué comme terminé et trié sous le travail en cours, pendant les mêmes 30 secondes que l’indice du pied de page. Sa vue détaillée reste ouverte lorsque le sous-agent se termine. Les sous-agents qui échouent ou que vous arrêtez quittent la liste. Avant la v2.1.208, un sous-agent terminé quittait la liste au moment où il se terminait et sa vue détaillée se fermait.

Noms des sous-agents

Claude peut donner un nom à un sous-agent en passant un paramètre name sur l’appel de l’outil Agent, et peut le faire de sa propre initiative, sans vous demander d’abord. Le nom rend le sous-agent adressable : Claude peut lui envoyer un message ou le reprendre par nom après sa fin. Dans une session interactive avec les équipes d’agents activées, un sous-agent que Claude génère à partir de la conversation principale avec un name se lance en tant que coéquipier à la place, sauf si l’appel est un fork ou passe isolation sur l’appel lui-même. Une valeur isolation dans le frontmatter du sous-agent ne l’empêche pas, et le coéquipier s’exécute alors dans le répertoire de travail de la session principale. Voir Comment Claude démarre les équipes d’agents.

Erreurs API dans les sous-agents

Lorsque quelque chose coupe la réponse d’un sous-agent en cours de flux, et que la réponse partielle contient du texte mais pas d’appels d’outils, Claude Code demande au sous-agent de continuer plutôt que de terminer l’exécution. Cela se produit également dans les sessions interactives. L’exécution se termine sur l’erreur uniquement une fois que ces continuations sont épuisées. Un sous-agent dont l’exécution se termine sur une erreur API, comme une limite d’utilisation ou une erreur serveur répétée, signale cet échec à Claude. Ce que Claude reçoit dépend de l’endroit où le sous-agent s’est exécuté :
  • Premier plan : si une limite de débit, une surcharge ou une erreur serveur coupe un sous-agent qui a déjà produit une sortie texte, l’outil Agent retourne cette sortie partielle avec une note indiquant que le sous-agent a été coupé et n’a pas terminé sa tâche. Un sous-agent qui n’a rien produit, ou dont la seule sortie était des appels d’outils, échoue avec Agent terminated early due to an API error, suivi du détail de l’erreur.
  • Arrière-plan : le sous-agent est marqué comme échoué, et le message que Claude reçoit lorsqu’il se termine nomme l’erreur API et inclut la dernière sortie du sous-agent, de sorte que le travail partiel n’est pas perdu.
Si le rapport d’un sous-agent commence par la ligne suivante, le sous-agent s’est terminé sur un modèle de secours :
Lorsque vous configurez une chaîne de modèles de secours et qu’un sous-agent rencontre une défaillance que la chaîne couvre, comme l’indisponibilité de son modèle, Claude Code bascule le sous-agent vers le premier modèle de la chaîne qui accepte la requête. Le sous-agent continue à travailler au lieu de se terminer sur l’erreur. Une fois que l’erreur API sous-jacente est résolue, demandez à Claude de réessayer la tâche ou de reprendre le sous-agent.

Analyse de la sortie des sous-agents

Claude Code analyse le rapport final de chaque sous-agent avant que Claude ne le lise. Un sous-agent peut avoir lu des fichiers, des pages Web ou une sortie de commande que vous n’avez jamais examinés, et le texte de ces sources peut contenir des instructions destinées à la conversation principale. L’analyse ne supprime ni ne reformule rien ; elle apporte deux types de changements que vous pouvez remarquer dans un rapport :
  • Insertion de barre oblique inverse : l’analyse insère une barre oblique inverse dans le texte qui imite la sortie propre de Claude Code, comme une balise <system-reminder> ou une ligne commençant par Human: ou Assistant:, de sorte que l’imitation se lit comme du texte ordinaire au lieu d’être prise pour une partie de la conversation.
  • Ligne de marqueur : l’analyse ajoute une ligne commençant par [harness: subagent output matched instruction-shaped pattern(s): lorsque le rapport imite une balise comme <system-reminder> ou mentionne des paramètres de permission comme bypassPermissions ou --dangerously-skip-permissions. Les mentions de paramètres de permission reçoivent la ligne de marqueur, mais le texte lui-même reste tel qu’écrit.
L’analyse ne juge pas si le contenu est malveillant, et elle ne change pas ce qu’une instruction dans un rapport peut faire : un appel d’outil que le rapport amène Claude à faire passe toujours par les vérifications de permission et le sandboxing de la session. Ce n’est pas un substitut à restreindre ce qu’un sous-agent peut atteindre. Un rapport qui revient à Claude en tant que résultat du sous-agent arrive également sous un en-tête le marquant comme sortie de sous-agent. L’en-tête indique que les instructions ou les affirmations d’approbation à l’intérieur du rapport sont les paroles du sous-agent et ne portent aucune autorité de votre part. Un rapport de sous-agent en arrière-plan arrive à l’intérieur d’une notification d’achèvement, qui est marquée comme un événement automatisé plutôt qu’un message de votre part.

Modèles courants

Isoler les opérations à haut volume

L’une des utilisations les plus efficaces des sous-agents est l’isolation des opérations qui produisent de grandes quantités de sortie. L’exécution de tests, la récupération de documentation ou le traitement de fichiers de logs peuvent consommer un contexte important. En déléguant ces tâches à un sous-agent, la sortie détaillée reste dans le contexte du sous-agent tandis que seul le résumé pertinent revient à votre conversation principale.

Exécuter des recherches en parallèle

Pour les investigations indépendantes, générez plusieurs sous-agents pour travailler simultanément :
Chaque sous-agent explore son domaine indépendamment, puis Claude synthétise les conclusions. Cela fonctionne mieux lorsque les chemins de recherche ne dépendent pas les uns des autres.
Lorsque les sous-agents se terminent, leurs résultats reviennent à votre conversation principale. L’exécution de nombreux sous-agents qui retournent chacun des résultats détaillés peut consommer un contexte important, et chaque sous-agent dépense ses propres tokens pendant qu’il s’exécute.
Pour le travail qui doit continuer à s’exécuter en parallèle ou qui ne tiendra pas dans une fenêtre de contexte, exécutez-le dans des sessions séparées et laissez Claude transmettre les conclusions entre elles.

Chaîner les sous-agents

Pour les workflows multi-étapes, demandez à Claude d’utiliser les sous-agents en séquence. Chaque sous-agent termine sa tâche et retourne les résultats à Claude, qui transmet ensuite le contexte pertinent au sous-agent suivant.

Choisir entre les sous-agents et la conversation principale

Utilisez la conversation principale lorsque :
  • La tâche nécessite des allers-retours fréquents ou un raffinement itératif
  • Plusieurs phases partagent un contexte important, comme la planification, l’implémentation et les tests
  • Vous apportez une modification rapide et ciblée
  • La latence est importante. Un sous-agent qui n’est pas un fork commence à zéro et peut avoir besoin de temps pour rassembler le contexte
Utilisez les sous-agents lorsque :
  • La tâche produit une sortie détaillée dont vous n’avez pas besoin dans votre contexte principal
  • Vous voulez appliquer des restrictions d’outils ou des permissions spécifiques
  • Le travail est autonome et peut retourner un résumé
Envisagez plutôt les skills lorsque vous voulez des prompts ou des workflows réutilisables qui s’exécutent dans le contexte de la conversation principale plutôt que dans un contexte de sous-agent isolé. Pour une question sur quelque chose déjà dans votre conversation, utilisez /btw au lieu d’un sous-agent. Il voit votre contexte complet mais n’a pas d’accès aux outils, et la réponse n’est pas ajoutée à l’historique.

Laisser les sous-agents générer leurs propres sous-agents

Par défaut, un sous-agent peut générer ses propres sous-agents, jusqu’à trois couches en dessous de la conversation principale. À la limite de profondeur, Claude Code retient l’outil Agent de tous les sous-agents sauf un fork, de sorte qu’un sous-agent à la limite fait son travail délégué lui-même et retourne un résumé. Un fork à la limite garde Agent dans sa liste d’outils héritée, mais l’outil retourne une erreur au lieu de générer. Les sous-agents imbriqués conviennent à une tâche déléguée qui elle-même se divise en sous-tâches parallèles, comme un sous-agent examinateur qui envoie un vérificateur par conclusion. Par défaut, le sous-agent de lancement attend le rapport de chaque sous-agent imbriqué :
  • Session de terminal interactive : seul le résumé du sous-agent de niveau supérieur vous revient, car un sous-agent qui lance des sous-agents en arrière-plan attend leurs résultats avant de se terminer.
  • claude -p et le SDK Agent : le sous-agent de lancement attend tant que le mode fork est activé. Si vous désactivez le mode fork, les sous-agents imbriqués démarrent en arrière-plan à la place. Le sous-agent de lancement n’attend pas un sous-agent imbriqué en arrière-plan, qui signale à votre conversation principale s’il survit au sous-agent de lancement.
Pour modifier la limite, définissez CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH sur le nombre de couches de sous-agents que vous voulez en dessous de votre conversation principale. Par exemple, cette entrée dans settings.json limite l’imbrication à deux couches :
Avec cette valeur, vos sous-agents peuvent déléguer à une deuxième couche de leurs propres, et cette deuxième couche ne peut pas déléguer davantage. Définissez 1 pour désactiver l’imbrication. Un sous-agent imbriqué est configuré de la même manière qu’un sous-agent de niveau supérieur et se résout à partir des mêmes portées. Pour empêcher un sous-agent de générer pendant que l’imbrication est activée, comme un examinateur qui doit rester en lecture seule, omettez Agent de sa liste tools ou ajoutez-le à disallowedTools. Dans le terminal, Claude Code affiche les sous-agents imbriqués sous forme d’arborescence dans le panneau des sous-agents sous la zone de saisie du prompt et marque chaque ligne qui a encore des descendants dans le panneau avec un nombre (+N) d’entre eux. Ouvrez une ligne pour voir les frères et sœurs de ce sous-agent et les enfants directs avec un chemin de retour à main.
Les versions antérieures utilisaient des valeurs par défaut différentes :
  • v2.1.172 à v2.1.216 : les sous-agents pouvaient s’imbriquer par défaut, jusqu’à cinq couches de profondeur, et la limite ne pouvait pas être modifiée.
  • v2.1.217 à v2.1.218 : la limite était définie par défaut à un, de sorte qu’un sous-agent ne pouvait pas générer le sien à moins que vous ne l’augmentiez ; v2.1.219 a augmenté la valeur par défaut à trois.

Limite de sous-agents concurrents

Deux limites contrôlent l’utilisation des sous-agents, chacune avec sa propre variable : celle-ci empêche Claude de générer plus de sous-agents pendant que trop d’entre eux s’exécutent, et la limite de profondeur limite la profondeur d’imbrication des sous-agents. Il n’y a pas de limite sur le nombre total de sous-agents que Claude peut générer au cours d’une session. Par défaut, lorsque 20 sous-agents s’exécutent dans une session, la génération d’un autre avec l’outil Agent échoue avec Concurrent subagent limit reached, et l’erreur indique à Claude de ne pas réessayer. La génération réussit à nouveau lorsque le nombre en cours d’exécution tombe en dessous de la limite. Pour modifier la limite, définissez CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS sur n’importe quel nombre entier positif. Les sessions avec ultracode actif sont exemptées : la limite n’est pas appliquée là. Nécessite Claude Code v2.1.217 ou ultérieure. La limite bloque uniquement les sous-agents que Claude génère avec l’outil Agent, mais d’autres exécutions occupent les mêmes emplacements :
  • Un fork en session que vous démarrez avec /subtask prend un emplacement pendant qu’il s’exécute et n’est jamais bloqué par la limite.
  • Reprendre un sous-agent qui a déjà terminé prend un nouvel emplacement sans vérifier la limite, de sorte que les reprises peuvent pousser le nombre en cours d’exécution au-delà.
Les agents que d’autres fonctionnalités exécutent, comme les agents workflow et les coéquipiers équipe d’agents, suivent leurs propres limites à la place.

Gérer le contexte des sous-agents

Ce qui se charge au démarrage

Chaque sous-agent démarre avec une fenêtre de contexte fraîche et isolée. Il ne voit pas votre historique de conversation, les skills que vous avez déjà invoqués, ou les fichiers que Claude a déjà lus. Claude compose un message de délégation qui résume la tâche, et le sous-agent travaille à partir de là. L’exception est un fork, qui hérite de la conversation parent au lieu de commencer à zéro. Le contexte initial d’un sous-agent non-fork contient :
  • Prompt système : le propre prompt de l’agent plus les détails d’environnement que Claude Code ajoute, pas le prompt système de Claude Code. Les sous-agents personnalisés définissent le leur dans le corps markdown ou le champ prompt. Les agents intégrés ont des prompts prédéfinis.
  • Message de tâche : le prompt de délégation que Claude rédige lorsqu’il confie le travail.
  • Fichiers CLAUDE.md : chaque niveau de la hiérarchie CLAUDE.md que la conversation principale charge, y compris ~/.claude/CLAUDE.md, les règles du projet, CLAUDE.local.md, les fichiers de politique gérés, et tous les fichiers AGENTS.md chargés en tant qu’instructions du projet. Les agents Explore et Plan intégrés ignorent cela. Un sous-agent dont la définition définit omitClaudeMd charge uniquement les fichiers de politique gérés, ou aucun lorsque la définition provient des paramètres gérés.
  • Statut Git : un instantané que Claude Code lit de votre dépôt lorsque le sous-agent démarre. Pour un sous-agent dans son propre worktree de ce dépôt, l’instantané affiche la branche, le statut et les commits récents du worktree. Absent en dehors d’un dépôt Git ou chaque fois que l’instantané est désactivé ; voir includeGitInstructions. Explore et Plan l’ignorent indépendamment.
  • Skills préchargés : contenu complet de tout skill nommé dans le champ skills de l’agent. Les agents intégrés ne préchargent pas les skills.
  • Roster des frères et sœurs : un rappel système listant main et tous les autres agents nommés dans la session, chacun une valeur to valide pour SendMessage. Le roster n’apparaît que lorsque les outils du sous-agent incluent SendMessage et qu’au moins un autre agent a un nom, que Claude l’ait nommé lors de sa génération ou qu’il s’exécute en tant que coéquipier équipe d’agents. C’est un instantané pris lorsque le sous-agent démarre, de sorte que les agents nommés plus tard n’apparaissent pas.
Pour lancer l’un de vos propres sous-agents sans les fichiers CLAUDE.md utilisateur, projet et local, définissez omitClaudeMd: true dans son frontmatter ou --agents JSON. Pour Explore, Plan et les sous-agents avec omitClaudeMd, le CLAUDE.md d’un sous-répertoire et les règles limitées à un chemin correspondantes se chargent toujours lorsque le sous-agent travaille avec des fichiers qui s’y trouvent. La conversation principale a toujours votre CLAUDE.md complet lorsqu’elle lit les résultats de ces sous-agents, de sorte que la plupart des règles n’ont pas besoin d’atteindre le sous-agent lui-même. Si une règle doit, comme « ignorer le répertoire vendor/ », reformulez-la dans le prompt que vous donnez à Claude lors de la délégation. Vous ne pouvez pas modifier les sous-agents qui reçoivent le statut git. Seuls Explore et Plan l’ignorent. Certains états de la conversation principale n’atteignent jamais un sous-agent non-fork :
  • Style de sortie : un sous-agent exécute son propre prompt système, de sorte que votre style de sortie ne façonne pas ses réponses, sauf dans un fork.
  • Mémoire automatique : la mémoire automatique de la conversation principale n’est pas chargée. Pour donner à un sous-agent une mémoire persistante qui lui est propre, utilisez le champ memory.
  • Taille de la fenêtre de contexte : la fenêtre de contexte d’un sous-agent est dimensionnée par son propre modèle, pas celle du parent. Déléguer à un modèle avec une fenêtre plus petite donne à ce sous-agent la fenêtre plus petite.

Reprendre les sous-agents

Chaque invocation de sous-agent crée une nouvelle instance plutôt que de continuer une instance antérieure. Pour continuer le travail d’un sous-agent existant au lieu de recommencer, demandez à Claude de le reprendre. Les sous-agents repris conservent leur historique de conversation complet, y compris tous les appels d’outils précédents, les résultats et le raisonnement. Si le sous-agent a généré ses propres sous-agents en arrière-plan, cet historique inclut les résultats qu’ils ont livrés pendant qu’il s’exécutait. Avant la v2.1.304, un sous-agent auquel Claude envoyait un message ou qu’il reprenait juste après sa fin pouvait oublier son travail le plus récent.
  • Lorsqu’un sous-agent se termine, Claude reçoit son ID d’agent.
  • Les agents Explore et Plan intégrés sont ponctuels et ne retournent pas d’ID d’agent, de sorte que Claude ne peut pas les reprendre. Utilisez general-purpose ou un sous-agent personnalisé lorsque vous avez besoin de continuer le travail.
  • Lorsqu’un sous-agent s’arrête à sa limite maxTurns, Claude Code marque la sortie retournée comme partielle, et Claude peut reprendre le sous-agent pour continuer son travail.
Claude utilise l’outil SendMessage avec l’ID ou le nom de l’agent comme champ to pour le reprendre. SendMessage ne nécessite pas que les équipes d’agents soient activées ; seuls les messages de protocole d’équipe structurés comme shutdown_request et plan_approval_response le font. Au-delà des sous-agents et des coéquipiers, dans les sessions où la messagerie inter-sessions est activée, Claude peut utiliser le même outil pour envoyer un message à vos autres sessions Claude Code, sur cette machine ou au-delà. Pour reprendre un sous-agent, demandez à Claude de continuer le travail précédent :
Lorsque Claude envoie un message à un sous-agent terminé avec l’outil SendMessage, le sous-agent reprend en arrière-plan sans une nouvelle invocation Agent. Il en va de même pour un sous-agent que Claude a arrêté avec l’outil TaskStop, une fois que son exécution arrêtée a quitté. L’exécution reprise conserve l’ensemble d’outils d’où le sous-agent s’est d’abord exécuté et peut continuer à lire le cache de prompt que l’exécution originale a préchauffé. Un sous-agent qui a l’outil SendMessage peut envoyer ce message aussi. Dans une session interactive, l’agent repris signale alors au sous-agent qui l’a repris, pas à votre conversation principale. Ce sous-agent attend le résultat avant de terminer son propre travail. Lorsqu’un sous-agent envoie un message à un agent auquel il signale, comme son propre lanceur, Claude Code reprend cet agent sans rediriger ses résultats. Un sous-agent que vous avez arrêté vous-même, avec x dans /tasks ou une demande SDK stop_task, ne reprend pas automatiquement. Si Claude lui envoie un message, le message est refusé et Claude est informé que l’agent a été annulé. Pendant que la ligne de ce sous-agent est toujours dans le panneau des sous-agents, tapez dans sa transcription pour le reprendre vous-même. Après cela, un message de Claude peut le reprendre automatiquement à nouveau. La reprise démarre une nouvelle exécution de l’agent sous le même ID, de sorte qu’un sous-agent qui avait déjà échoué ou s’était terminé s’affiche à nouveau comme en cours d’exécution dans la liste des tâches et dans les événements de tâche du SDK Agent. SendMessage vérifie qu’un nom fait toujours référence au même agent qu’il a atteint plus tôt dans la conversation. Si un agent plus récent a pris le nom, comme un agent en arrière-plan re-généré qui l’a réutilisé, Claude Code refuse l’envoi plutôt que de le livrer au mauvais agent, et l’erreur signale quel agent le nom atteint maintenant pour que Claude puisse le rediriger. Pour atteindre l’agent antérieur pendant qu’il s’exécute toujours, Claude l’adresse par l’ID d’agent qu’il a reçu lorsqu’il a généré cet agent. La vérification est limitée à la conversation actuelle et se réinitialise sur /clear. Un sous-agent traite les messages de l’agent qui l’a lancé comme une direction de tâche normale, y compris les corrections de cours en cours de tâche, et agit en fonction de ses propres paramètres de permission. Deux limites tiennent indépendamment de qui a envoyé le message : aucun message d’aucun agent ne compte comme votre approbation pour une demande de permission en attente, et aucun message d’agent ne peut modifier les paramètres de permission, CLAUDE.md ou la configuration d’un sous-agent. Seul le système de permission ou vos propres messages peuvent accorder l’approbation. Vous pouvez également demander à Claude l’ID d’agent si vous voulez le référencer explicitement, ou trouver les ID dans les fichiers de transcription à ~/.claude/projects/{project}/{sessionId}/subagents/. Chaque transcription est stockée sous agent-{agentId}.jsonl. Les transcriptions des sous-agents persistent indépendamment de la conversation principale :
  • Compaction de la conversation principale : lorsque la conversation principale se compacte, les transcriptions des sous-agents ne sont pas affectées. Elles sont stockées dans des fichiers séparés.
  • Persistance de la session : les transcriptions des sous-agents persistent dans leur session. Vous pouvez reprendre un sous-agent après avoir redémarré Claude Code en reprenant la même session.
  • Nettoyage automatique : Claude Code supprime les transcriptions des sous-agents après la période de rétention cleanupPeriodDays, 30 jours par défaut, en suivant les règles de balayage de rétention.
Pour un sous-agent lancé en tant que coéquipier, consultez plutôt les limitations des équipes d’agents.
Si Claude ne peut pas envoyer de message à un sous-agent par son nom après que vous avez redémarré Claude Code et repris la session, donnez plutôt à Claude l’ID d’agent du sous-agent. Les noms que Claude a donnés depuis la conversation principale depuis sa dernière compaction survivent au redémarrage. Un nom antérieur à cette compaction ne survit pas. Pour trouver l’ID correspondant à un nom, recherchez ce nom dans les fichiers agent-{agentId}.meta.json de ~/.claude/projects/{project}/{sessionId}/subagents/. Après un message envoyé par ID, le nom du sous-agent fonctionne à nouveau, sauf si un agent plus récent a pris ce nom. Avant la v2.1.299, aucun nom ne survivait à un redémarrage, et un envoi par nom était refusé même lorsque l’ID d’agent fonctionnait encore.

Compaction automatique

Les sous-agents prennent en charge la compaction automatique. La compaction se déclenche à mesure que la propre fenêtre de contexte du sous-agent se remplit, et CLAUDE_AUTOCOMPACT_PCT_OVERRIDE s’applique également aux sous-agents. Voir variables d’environnement pour savoir quand le remplacement prend effet. Les événements de compaction sont consignés dans les fichiers de transcription des sous-agents :
La valeur preTokens indique le nombre de tokens utilisés avant la compaction. Pour qu’un sous-agent se compacte plus tôt qu’il ne le ferait autrement, définissez autoCompactWindow dans son frontmatter sur un nombre de tokens compris entre 100000 et 1000000. Si vous définissez CLAUDE_CODE_AUTO_COMPACT_WINDOW, le sous-agent utilise la fenêtre de cette variable à la place et le champ n’a aucun effet, sauf si Claude Code ignore la valeur de la variable. Nécessite Claude Code v2.1.296 ou ultérieure. Ce frontmatter définit autoCompactWindow sur 200 000 tokens pour un sous-agent qui lit de longs fichiers de logs :
Écrivez la valeur sous forme d’entier simple comme 200000, car dans le frontmatter, Claude Code lit 200k comme 200, ce qui est en dehors de la plage autorisée. Le sous-agent se charge et se compacte alors quand même comme si le champ était absent. Pour vérifier si Claude Code a ignoré votre valeur, exécutez claude --debug dans votre shell et recherchez invalid autoCompactWindow dans le log de débogage. Si la valeur est dans la plage et que vous ne constatez toujours aucun changement, vérifiez les causes suivantes :
  • La valeur n’est pas inférieure à la fenêtre de compaction automatique dont le sous-agent hériterait autrement : pour compacter plus tôt, définissez une valeur inférieure à cette fenêtre.
  • Vous exécutez toute la session en tant que ce sous-agent avec --agent ou le paramètre agent : le champ n’a aucun effet dans ce cas. Pour définir la fenêtre de la session, voir Définir la fenêtre de compaction automatique.

Dupliquer la conversation actuelle

Lorsque la vue agent est désactivée, /subtask n’est pas disponible et /fork démarre le sous-agent dupliqué à la place ; sinon /fork copie l’intégralité de la session dans une nouvelle session en arrière-plan.
Un fork est un sous-agent qui hérite de l’intégralité de la conversation jusqu’à présent au lieu de commencer à zéro. Cela supprime l’isolation d’entrée que les sous-agents fournissent autrement : un fork voit la même invite système, les mêmes outils, le même modèle et l’historique des messages que la session principale, vous pouvez donc lui confier une tâche secondaire sans réexpliquer la situation. Les appels d’outils du fork restent en dehors de votre conversation et seul son résultat final revient, donc votre fenêtre de contexte principal reste propre. Utilisez un fork lorsqu’un autre sous-agent aurait besoin de trop de contexte pour être utile, ou lorsque vous souhaitez essayer plusieurs approches en parallèle à partir du même point de départ. Claude peut démarrer un fork de lui-même lorsque le mode fork est activé, ce qui est le cas par défaut. Pour empêcher les forks, consultez Désactiver le mode fork. Vous pouvez démarrer un fork vous-même avec /subtask suivi d’une tâche, que le mode fork soit activé ou non. Claude Code nomme le fork à partir des premiers mots de la tâche. L’exemple suivant duplique la conversation pour rédiger des cas de test pendant que vous continuez avec l’implémentation dans la session principale :
Le fork apparaît dans un panneau sous votre invite et s’exécute en arrière-plan pendant que vous continuez à travailler. Lorsqu’il se termine, son résultat arrive sous forme de message dans votre conversation principale. La section suivante couvre les contrôles du panneau pour observer et diriger les forks pendant qu’ils s’exécutent.

Observer et diriger les forks en cours d’exécution

Les forks en cours d’exécution apparaissent dans un panneau sous l’entrée d’invite, avec une ligne pour la session principale et une pour chaque fork. Lorsqu’un fork se termine avec succès, Claude Code supprime sa ligne. Claude Code conserve la ligne d’un fork qui a échoué ou que vous avez arrêté pendant 30 secondes, identique à tout autre sous-agent en arrière-plan. Avant v2.1.232, Claude Code conservait également la ligne d’un fork terminé pendant 30 secondes. Utilisez ces touches pour interagir avec le panneau : Avec la transcription d’un fork ou d’un sous-agent ouverte, les messages de suivi et les skills vont à cet agent, et les commandes intégrées vont à votre conversation principale, avec ces garde-fous :
  • /compact, /clear et /rewind agissent sur la conversation principale, donc Claude Code vous demande de confirmer avant d’exécuter l’une d’elles depuis cette vue.
  • /model et /fast définissent le modèle et le mode rapide de la conversation principale, et non ceux de l’agent visualisé, donc elles ne s’exécutent pas depuis cette vue. Un avis vous en indique la raison.
Pour que l’agent visualisé lise votre message avant que le travail qu’il attend ne se termine, envoyez-le avec Ctrl+Enter ou Ctrl+X Ctrl+S. Toute commande shell ou tout sous-agent que l’agent attend et qui peut passer en arrière-plan y passe et continue de s’exécuter. Lorsque l’agent rédige une réponse, ou attend un travail qui ne peut pas passer en arrière-plan, il continue et lit votre message une fois ce travail terminé. Nécessite Claude Code v2.1.286 ou version ultérieure.

Comment les forks diffèrent des autres sous-agents

Un fork hérite de tout ce que la session principale a au moment où il se génère. Tout autre sous-agent démarre à partir de sa définition. Comme le prompt système d’un fork et ses définitions d’outils sont identiques à ceux du parent, sa première requête réutilise le cache de prompt du parent. Grâce à cette réutilisation, un fork coûte moins cher qu’un sous-agent frais pour les tâches qui ont besoin du même contexte. Lorsque Claude génère un fork via l’outil Agent, il peut passer isolation: "worktree" pour que les modifications de fichiers du fork soient écrites dans un git worktree séparé au lieu de votre extraction. Un fork ne peut pas générer d’autres forks.

Désactiver le mode fork

Le mode fork permet à Claude de démarrer un fork de lui-même. Pour empêcher Claude de démarrer des forks : Lorsque le mode fork est activé, Claude ne peut pas non plus attendre un sous-agent dans les sessions interactives du terminal, de VS Code ou de l’application de bureau sur votre machine. Le mode fork est activé par défaut à partir de Claude Code v2.1.302, et dans une session interactive du terminal à partir de v2.1.232.

Exemples de sous-agents

Ces exemples démontrent des modèles efficaces pour construire des sous-agents. Utilisez-les comme points de départ, ou générez une version personnalisée avec Claude.
Meilleures pratiques :
  • Concevoir des sous-agents ciblés : chaque sous-agent doit exceller dans une tâche spécifique
  • Écrire des descriptions qui mettent en avant un seul sous-agent : Claude utilise la description pour décider quand déléguer. Rendez chaque description suffisamment spécifique pour router vers le bon sous-agent, et gardez l’ensemble combiné dans le budget de description de 15 000 jetons
  • Limiter l’accès aux outils : accordez uniquement les permissions nécessaires pour la sécurité et la concentration
  • Enregistrer dans le contrôle de version : partagez les sous-agents de projet avec votre équipe

Examinateur de code

Un sous-agent en lecture seule qui examine le code sans le modifier. Cet exemple montre comment concevoir un sous-agent ciblé avec un accès limité aux outils qui exclut Edit et Write, et une invite détaillée qui spécifie exactement ce qu’il faut chercher et comment formater la sortie.

Débogueur

Un sous-agent qui peut à la fois analyser et corriger les problèmes. Contrairement à l’examinateur de code, celui-ci inclut Edit car corriger les bugs nécessite de modifier le code. L’invite fournit un workflow clair du diagnostic à la vérification.

Data scientist

Un sous-agent spécialisé dans le domaine pour le travail d’analyse de données. Cet exemple montre comment créer des sous-agents pour des workflows spécialisés en dehors des tâches de codage typiques. Il définit explicitement model: sonnet pour une analyse plus capable.

Validateur de requête de base de données

Un sous-agent qui autorise l’accès à Bash mais valide les commandes pour n’autoriser que les requêtes SQL en lecture seule. Cet exemple montre comment utiliser les hooks PreToolUse pour la validation conditionnelle lorsque vous avez besoin d’un contrôle plus fin que le champ tools ne le permet.
Claude Code passe l’entrée du hook en JSON via stdin aux commandes du hook. Le script de validation lit ce JSON, extrait la commande en cours d’exécution et la vérifie par rapport à une liste d’opérations d’écriture SQL. Si une opération d’écriture est détectée, le script quitte avec le code 2 pour bloquer l’exécution et retourne un message d’erreur à Claude via stderr. Créez le script de validation n’importe où dans votre projet. Le chemin doit correspondre au champ command dans votre configuration de hook :
Sur macOS et Linux, rendez le script exécutable :
Sur Windows, écrivez le script de validation en PowerShell et ajoutez shell: powershell à l’entrée du hook. Consultez exécution des hooks dans PowerShell. Le hook reçoit JSON via stdin avec la commande Bash dans tool_input.command. Le code de sortie 2 bloque l’opération et renvoie le message d’erreur à Claude. Consultez Hooks pour plus de détails sur les codes de sortie et Hook input pour le schéma d’entrée complet. L’invite système indique au sous-agent de refuser les demandes d’écriture, donc le hook est une sauvegarde : si le sous-agent tente une écriture de toute façon, Claude Code bloque la commande et le sous-agent voit le message Blocked: Write operations not allowed. Use SELECT queries only..

Étapes suivantes

Maintenant que vous comprenez les sous-agents, explorez ces fonctionnalités connexes :