Passer au contenu principal

Installation

Installez le package dans un environnement virtuel. Sur les installations récentes de Debian, Ubuntu et Homebrew Python, l’exécution de pip install contre le Python système échoue avec error: externally-managed-environment.
Pour uv, Windows PowerShell et la configuration de la clé API, consultez Démarrer dans la vue d’ensemble du Agent SDK.

Choisir entre query() et ClaudeSDKClient

Le SDK Python offre deux façons d’interagir avec Claude Code :

Comparaison rapide

Quand utiliser query() (tâches ponctuelles)

Idéal pour :
  • Les questions ponctuelles où vous n’avez pas besoin d’historique de conversation
  • Les tâches indépendantes qui ne nécessitent pas de contexte des échanges précédents
  • Les scripts d’automatisation simples
  • Quand vous voulez un nouveau départ à chaque fois

Quand utiliser ClaudeSDKClient (conversation continue)

Idéal pour :
  • Continuer les conversations - Quand vous avez besoin que Claude se souvienne du contexte
  • Questions de suivi - S’appuyer sur les réponses précédentes
  • Applications interactives - Interfaces de chat, REPLs
  • Logique basée sur les réponses - Quand l’action suivante dépend de la réponse de Claude
  • Contrôle de session - Gérer explicitement le cycle de vie de la conversation

Fonctions

query()

Crée une nouvelle session pour chaque interaction avec Claude Code par défaut. Retourne un itérateur asynchrone qui produit les messages au fur et à mesure qu’ils arrivent. Chaque appel à query() recommence à zéro sans mémoire des interactions précédentes, sauf si vous passez continue_conversation=True ou resume dans ClaudeAgentOptions. Voir Sessions.

Paramètres

Retours

Retourne un AsyncIterator[Message] qui produit les messages de la conversation.

Exemple - Avec options

tool()

Décorateur pour définir des outils MCP avec sécurité des types.

Paramètres

Options de schéma d’entrée

  1. Mappage de type simple (recommandé) :
  2. Format JSON Schema (pour la validation complexe) :

Retours

Une fonction décorateur qui enveloppe l’implémentation de l’outil et retourne une instance SdkMcpTool.

Exemple

ToolAnnotations

Réexportée depuis mcp.types (également disponible via from claude_agent_sdk import ToolAnnotations). Tous les champs sont des indices optionnels ; les clients ne doivent pas s’y fier pour les décisions de sécurité.

create_sdk_mcp_server()

Crée un serveur MCP en processus qui s’exécute dans votre application Python.

Paramètres

Retours

Retourne un objet McpSdkServerConfig qui peut être passé à ClaudeAgentOptions.mcp_servers.

Exemple

list_sessions()

Liste les sessions passées avec métadonnées. Filtrez par répertoire de projet ou listez les sessions dans tous les projets. Synchrone ; retourne immédiatement.

Paramètres

Type de retour : SDKSessionInfo

Exemple

Affiche les 10 sessions les plus récentes pour un projet. Les résultats sont triés par last_modified décroissant, donc le premier élément est le plus récent. Omettez directory pour rechercher dans tous les projets.

get_session_messages()

Récupère les messages d’une session passée. Synchrone ; retourne immédiatement.

Paramètres

Type de retour : SessionMessage

Exemple

get_session_info()

Lit les métadonnées d’une seule session par ID sans scanner le répertoire de projet complet. Synchrone ; retourne immédiatement.

Paramètres

Retourne SDKSessionInfo, ou None si la session n’est pas trouvée.

Exemple

Recherchez les métadonnées d’une seule session sans scanner le répertoire de projet. Utile quand vous avez déjà un ID de session d’une exécution précédente.

rename_session()

Renomme une session en ajoutant une entrée de titre personnalisé. Les appels répétés sont sûrs ; le titre le plus récent gagne. Synchrone.

Paramètres

Lève ValueError si session_id n’est pas un UUID valide ou si title est vide ; FileNotFoundError si la session ne peut pas être trouvée.

Exemple

Renommez la session la plus récente pour qu’elle soit plus facile à trouver plus tard. Le nouveau titre apparaît dans SDKSessionInfo.custom_title lors des lectures ultérieures.

tag_session()

Étiquette une session. Passez None pour effacer l’étiquette. Les appels répétés sont sûrs ; l’étiquette la plus récente gagne. Synchrone.

Paramètres

Lève ValueError si session_id n’est pas un UUID valide ou si tag est vide après nettoyage ; FileNotFoundError si la session ne peut pas être trouvée.

Exemple

Étiquetez une session, puis filtrez par cette étiquette lors d’une lecture ultérieure. Passez None pour effacer une étiquette existante.

Classes

ClaudeSDKClient

Maintient une session de conversation sur plusieurs échanges. C’est l’équivalent Python de la façon dont la fonction query() du SDK TypeScript fonctionne en interne - elle crée un objet client qui peut continuer les conversations.

Fonctionnalités clés

  • Continuité de session : Maintient le contexte de conversation sur plusieurs appels query()
  • Même conversation : La session conserve les messages précédents
  • Support des interruptions : Peut arrêter l’exécution en cours de tâche
  • Cycle de vie explicite : Vous contrôlez quand la session commence et se termine
  • Flux basé sur les réponses : Peut réagir aux réponses et envoyer des suivis
  • Outils personnalisés et hooks : Supporte les outils personnalisés (créés avec le décorateur @tool) et les hooks

Méthodes

Support du gestionnaire de contexte

Le client peut être utilisé comme un gestionnaire de contexte asynchrone pour la gestion automatique de la connexion :
Important : Lors de l’itération sur les messages, évitez d’utiliser break pour quitter tôt car cela peut causer des problèmes de nettoyage asyncio. À la place, laissez l’itération se terminer naturellement ou utilisez des drapeaux pour suivre quand vous avez trouvé ce que vous cherchiez.

Exemple - Continuer une conversation

Exemple - Entrée en streaming avec ClaudeSDKClient

Exemple - Utiliser les interruptions

Comportement du buffer après interruption : interrupt() envoie un signal d’arrêt mais ne vide pas le buffer de messages. Les messages déjà produits par la tâche interrompue, incluant son ResultMessage (avec subtype="error_during_execution"), restent dans le flux. Vous devez les vider avec receive_response() avant de lire la réponse à une nouvelle requête. Si vous envoyez une nouvelle requête immédiatement après interrupt() et appelez receive_response() une seule fois, vous recevrez les messages de la tâche interrompue, pas la réponse de la nouvelle requête.

Exemple - Contrôle avancé des permissions

Types

@dataclass vs TypedDict : Ce SDK utilise deux types de types. Les classes décorées avec @dataclass (telles que ResultMessage, AgentDefinition, TextBlock) sont des instances d’objet à l’exécution et supportent l’accès par attribut : msg.result. Les classes définies avec TypedDict (telles que ThinkingConfigEnabled, McpStdioServerConfig, SyncHookJSONOutput) sont des dicts simples à l’exécution et nécessitent l’accès par clé : config["budget_tokens"], pas config.budget_tokens. La syntaxe d’appel ClassName(field=value) fonctionne pour les deux, mais seules les dataclasses produisent des objets avec des attributs.

SdkMcpTool

Définition pour un outil MCP SDK créé avec le décorateur @tool.

Transport

Classe de base abstraite pour les implémentations de transport personnalisées. Utilisez ceci pour communiquer avec le processus Claude sur un canal personnalisé (par exemple, une connexion distante au lieu d’un sous-processus local).
C’est une API interne de bas niveau. L’interface peut changer dans les versions futures. Les implémentations personnalisées doivent être mises à jour pour correspondre à tout changement d’interface.
Importation : from claude_agent_sdk import Transport

ClaudeAgentOptions

Dataclass de configuration pour les requêtes Claude Code.

Gérer les réponses API lentes ou bloquées

Le sous-processus CLI lit plusieurs variables d’environnement qui contrôlent les délais d’expiration de l’API et la détection de blocage. Passez-les via ClaudeAgentOptions.env :
  • API_TIMEOUT_MS : délai d’expiration par requête sur le client Anthropic, en millisecondes. Par défaut 600000. S’applique à la boucle principale et à tous les sous-agents.
  • CLAUDE_CODE_MAX_RETRIES : nombre maximum de tentatives API. Par défaut 10, limité à 15. Chaque tentative obtient sa propre fenêtre API_TIMEOUT_MS, donc le pire temps mural est approximativement API_TIMEOUT_MS × (CLAUDE_CODE_MAX_RETRIES + 1) plus le backoff. Pour les exécutions sans surveillance qui doivent attendre des pannes plus longues, définissez CLAUDE_CODE_RETRY_WATCHDOG=1 : il réessaye les erreurs de capacité indéfiniment, et à partir de Claude Code v2.1.199 augmente la valeur par défaut pour les autres erreurs transitoires à 300 et supprime le plafond sur cette variable.
  • CLAUDE_ASYNC_AGENT_STALL_TIMEOUT_MS : chien de garde de blocage pour les sous-agents lancés avec run_in_background. Par défaut 600000. Réinitialise à chaque événement de flux ; en cas de blocage, il abandonne le sous-agent, marque la tâche comme échouée et expose l’erreur au parent avec tout résultat partiel. Ne s’applique pas aux sous-agents synchrones.
  • CLAUDE_ENABLE_STREAM_WATCHDOG avec CLAUDE_STREAM_IDLE_TIMEOUT_MS : abandonne la requête quand les en-têtes sont arrivés mais le corps de la réponse cesse de faire du streaming. Le chien de garde est activé par défaut pour tous les fournisseurs ; définissez CLAUDE_ENABLE_STREAM_WATCHDOG=0 pour le désactiver. CLAUDE_STREAM_IDLE_TIMEOUT_MS par défaut à 300000 et est limité à ce minimum. La requête abandonnée passe par le chemin de tentative normal.

OutputFormat

Configuration pour la validation de sortie structurée. Passez ceci comme un dict au champ output_format sur ClaudeAgentOptions :

SystemPromptPreset

Configuration pour utiliser le preset de prompt système de Claude Code avec des ajouts optionnels.

SystemPromptFile

Configuration pour charger un prompt système personnalisé à partir d’un fichier au lieu de le passer en tant que chaîne. Le SDK mappe ceci à l’indicateur CLI --system-prompt-file. Utilisez la forme fichier quand le prompt est volumineux : le SDK passe un system_prompt chaîne sur l’argv du sous-processus CLI, qui est soumis aux limites de longueur de ligne de commande du système d’exploitation avant que le SDK n’envoie une requête API. Sur Linux, un seul argument plus long que environ 128 KB échoue au spawn du processus avec Argument list too long. Sur Windows, la ligne de commande entière est limitée à environ 32 KB, donc la forme chaîne échoue à un seuil inférieur.

SettingSource

Contrôle quelles sources de configuration basées sur le système de fichiers le SDK charge les paramètres à partir de.

Comportement par défaut

Quand setting_sources est omis ou None, query() charge les mêmes paramètres du système de fichiers que le CLI Claude Code : utilisateur, projet et local. Les paramètres de politique gérée sont chargés dans tous les cas ; les paramètres gérés par le serveur sont récupérés quand la session s’authentifie avec une credential d’organisation sur une configuration éligible. Voir Ce que settingSources ne contrôle pas pour les entrées qui sont lues indépendamment de cette option, et comment les désactiver.

Pourquoi utiliser setting_sources

Désactiver les paramètres du système de fichiers :
Dans le SDK Python 0.1.59 et antérieur, une liste vide était traitée de la même manière que l’omission de l’option, donc setting_sources=[] n’a pas désactivé les paramètres du système de fichiers. Mettez à niveau vers une version plus récente si vous avez besoin qu’une liste vide prenne effet. Le SDK TypeScript n’est pas affecté.
Charger tous les paramètres du système de fichiers explicitement :
Charger uniquement des sources de paramètres spécifiques :
Environnements de test et CI :
Applications SDK uniquement :
Chargement des instructions de projet CLAUDE.md :

Précédence des paramètres

Quand plusieurs sources sont chargées, les paramètres sont fusionnés avec cette précédence (la plus haute à la plus basse) :
  1. Paramètres locaux (.claude/settings.local.json)
  2. Paramètres de projet (.claude/settings.json)
  3. Paramètres utilisateur (~/.claude/settings.json)
Les options programmatiques telles que agents et allowed_tools remplacent les paramètres du système de fichiers utilisateur, projet et local. Les paramètres de politique gérée prennent la priorité sur les options programmatiques.

AgentDefinition

Configuration pour un sous-agent défini programmatiquement.
Les noms de champs AgentDefinition utilisent camelCase, tels que disallowedTools, permissionMode, et maxTurns. Ces noms correspondent directement au format de fil partagé avec le SDK TypeScript. Ceci diffère de ClaudeAgentOptions, qui utilise Python snake_case pour les champs de niveau supérieur équivalents tels que disallowed_tools et permission_mode. Parce que AgentDefinition est une dataclass, passer un mot-clé snake_case lève une TypeError au moment de la construction.

PermissionMode

Modes de permission pour contrôler l’exécution des outils.

EffortLevel

Niveaux d’effort pour guider la profondeur de réflexion.

CanUseTool

Alias de type pour les fonctions de callback de permission d’outil.
Le callback reçoit :
  • tool_name : Nom de l’outil en cours d’appel
  • input_data : Les paramètres d’entrée de l’outil
  • context : Un ToolPermissionContext avec des informations supplémentaires
Retourne un PermissionResult (soit PermissionResultAllow soit PermissionResultDeny). Le callback est le remplacement SDK pour le prompt de permission interactif : il est invoqué uniquement quand le flux d’évaluation de permission aboutit à un prompt. Les appels d’outil déjà approuvés par une entrée allowed_tools, une règle d’autorisation des paramètres, ou le mode de permission, tel que acceptEdits ou bypassPermissions, ne l’invoquent jamais. Pour contrôler chaque appel d’outil, utilisez un hook PreToolUse à la place. AskUserQuestion, les outils MCP marqués requiresUserInteraction, et les outils connecteur que votre organisation a défini sur ask l’atteignent même quand une règle d’autorisation correspond. En mode dontAsk ces appels sont refusés à la place, sans invoquer le callback.

ToolPermissionContext

Informations de contexte passées aux callbacks de permission d’outil.

PermissionResult

Type union pour les résultats de callback de permission.

PermissionResultAllow

Résultat indiquant que l’appel d’outil doit être autorisé.

PermissionResultDeny

Résultat indiquant que l’appel d’outil doit être refusé.

PermissionUpdate

Configuration pour mettre à jour les permissions programmatiquement.

PermissionRuleValue

Une règle à ajouter, remplacer ou supprimer dans une mise à jour de permission.

ToolsPreset

Configuration des outils preset pour utiliser l’ensemble d’outils par défaut de Claude Code.

ThinkingConfig

Contrôle le comportement de la réflexion étendue. Une union de trois configurations :
Le champ optionnel display contrôle si le texte de réflexion est retourné "summarized" ou "omitted". Sur Claude Opus 4.7 et ultérieur, la valeur par défaut de l’API est "omitted", donc définissez "summarized" pour recevoir le contenu de réflexion dans les sorties ThinkingBlock. Parce que ce sont des classes TypedDict, ce sont des dicts simples à l’exécution. Construisez-les soit comme des littéraux dict soit appelez la classe comme un constructeur ; les deux produisent un dict. Accédez aux champs avec config["budget_tokens"], pas config.budget_tokens :

SdkBeta

Type littéral pour les fonctionnalités bêta du SDK.
Utilisez avec le champ betas dans ClaudeAgentOptions pour activer les fonctionnalités bêta.
La bêta context-1m-2025-08-07 est retirée à partir du 30 avril 2026. Passer cet en-tête avec Claude Sonnet 4.5 ou Sonnet 4 n’a aucun effet, et les requêtes qui dépassent la fenêtre de contexte standard de 200 000 tokens retournent une erreur. Pour utiliser une fenêtre de contexte de 1 million de tokens, migrez vers Claude Sonnet 5, Claude Sonnet 4.6, Claude Opus 4.6, Claude Opus 4.7, ou Claude Opus 4.8, qui incluent 1 million de contexte à prix standard sans en-tête bêta requis.

McpSdkServerConfig

Configuration pour les serveurs MCP SDK créés avec create_sdk_mcp_server().

McpServerConfig

Type union pour les configurations de serveur MCP.

McpStdioServerConfig

McpSSEServerConfig

McpHttpServerConfig

McpServerStatusConfig

La configuration d’un serveur MCP telle que rapportée par get_mcp_status(). C’est l’union de toutes les variantes de transport McpServerConfig plus une variante de sortie uniquement claudeai-proxy pour les serveurs proxifiés via claude.ai.
McpSdkServerConfigStatus est la forme sérialisable de McpSdkServerConfig avec seulement les champs type ("sdk") et name (str) ; l’instance en processus est omise. McpClaudeAIProxyServerConfig a les champs type ("claudeai-proxy"), url (str), et id (str).

McpStatusResponse

Réponse de ClaudeSDKClient.get_mcp_status(). Enveloppe la liste des statuts de serveur sous la clé mcpServers.

McpServerStatus

Statut d’un serveur MCP connecté, contenu dans McpStatusResponse.

SdkPluginConfig

Configuration pour charger les plugins dans le SDK.
Exemple :
Pour des informations complètes sur la création et l’utilisation de plugins, voir Plugins.

Types de messages

Message

Type union de tous les messages possibles.

UserMessage

Message d’entrée utilisateur.

AssistantMessage

Message de réponse d’assistant avec blocs de contenu.

AssistantMessageError

Types d’erreur possibles pour les messages d’assistant.

SystemMessage

Message système avec métadonnées.

ResultMessage

Message de résultat final avec informations de coût et d’utilisation.
Le champ subtype détermine quels autres champs sont remplis. C’est l’un de "success", "error_during_execution", "error_max_turns", "error_max_budget_usd", ou "error_max_structured_output_retries". La dataclass Python aplatit toutes les variantes en une seule forme, donc les champs qui ne s’appliquent pas au sous-type retourné sont None. Plusieurs champs portent des détails de diagnostic quand la conversation se termine sur une erreur :
  • is_error : True quand la conversation s’est terminée dans un état d’erreur. Toujours True sur les sous-types error_*. Sur subtype="success" c’est True quand la dernière demande de modèle a échoué, ce qui signifie que la boucle d’agent s’est terminée mais le dernier appel API a retourné une erreur.
  • api_error_status : le code de statut HTTP de l’erreur API terminale. None quand le tour s’est terminé sans une. Rempli uniquement sur subtype="success".
  • result : texte du message d’assistant final sur subtype="success", ou None sur les sous-types error_*. Quand subtype="success" et is_error=True, ceci contient la chaîne d’erreur API si une est disponible mais peut être vide, donc vérifiez api_error_status et le contenu AssistantMessage précédent pour plus de détails.
  • errors : chaînes d’erreur au niveau de la boucle telles que le message max-turns. Rempli uniquement sur les sous-types error_*.
Le dict usage contient les clés suivantes quand présentes : Le dict model_usage mappe les noms de modèles à l’utilisation par modèle. Les clés du dict interne utilisent camelCase parce que la valeur est passée inchangée du processus CLI sous-jacent, correspondant au type TypeScript ModelUsage :

StreamEvent

Événement de flux pour les mises à jour de messages partiels pendant le streaming. Reçu uniquement quand include_partial_messages=True dans ClaudeAgentOptions. Importez via from claude_agent_sdk.types import StreamEvent.

RateLimitEvent

Émis quand le statut de limite de débit change (par exemple, de "allowed" à "allowed_warning"). Utilisez ceci pour avertir les utilisateurs avant qu’ils ne frappent une limite dure, ou pour reculer quand le statut est "rejected".

RateLimitInfo

État de limite de débit porté par RateLimitEvent.

TaskStartedMessage

Émis quand une tâche de fond démarre. Une tâche de fond est tout ce qui est suivi en dehors du tour principal : une commande Bash en arrière-plan, une montre Monitor, un sous-agent généré via l’outil Agent, ou un agent distant. Le champ task_type vous dit lequel. Ce nommage n’est pas lié au renommage de l’outil Task-à-Agent.

TaskUsage

Données de tokens et de timing pour une tâche de fond.

TaskProgressMessage

Émis périodiquement avec les mises à jour de progression pour une tâche de fond en cours d’exécution.

TaskNotificationMessage

Émis quand une tâche de fond se termine, échoue, ou est arrêtée. Les tâches de fond incluent les commandes Bash run_in_background, les montres Monitor, et les sous-agents en arrière-plan.

Types de blocs de contenu

ContentBlock

Type union de tous les blocs de contenu.

TextBlock

Bloc de contenu texte.

ThinkingBlock

Bloc de contenu de réflexion (pour les modèles avec capacité de réflexion).

ToolUseBlock

Bloc de requête d’utilisation d’outil.

ToolResultBlock

Bloc de résultat d’exécution d’outil.

Types d’erreur

ClaudeSDKError

Classe d’exception de base pour toutes les erreurs du SDK.

CLINotFoundError

Levée quand Claude Code CLI n’est pas installé ou introuvable.

CLIConnectionError

Levée quand la connexion à Claude Code échoue.

ProcessError

Levée quand le processus Claude Code échoue.

CLIJSONDecodeError

Levée quand l’analyse JSON échoue.

Types de hooks

Pour un guide complet sur l’utilisation des hooks avec des exemples et des modèles courants, voir le guide Hooks.

HookEvent

Types d’événements de hook supportés.
Le SDK TypeScript supporte des événements de hook supplémentaires non encore disponibles en Python : SessionStart, SessionEnd, Setup, TeammateIdle, TaskCompleted, ConfigChange, WorktreeCreate, WorktreeRemove, PostToolBatch et MessageDisplay.

HookCallback

Définition de type pour les fonctions de callback de hook.
Paramètres :
  • input : Entrée de hook fortement typée avec unions discriminées basées sur hook_event_name (voir HookInput)
  • tool_use_id : Identifiant d’utilisation d’outil optionnel (pour les hooks liés aux outils)
  • context : Contexte de hook avec des informations supplémentaires
Retourne un HookJSONOutput qui peut contenir :
  • decision : "block" pour bloquer l’action
  • systemMessage : Message d’avertissement affiché à l’utilisateur
  • hookSpecificOutput : Données de sortie spécifiques au hook

HookContext

Informations de contexte passées aux callbacks de hook.

HookMatcher

Configuration pour faire correspondre les hooks à des événements ou des outils spécifiques.

HookInput

Type union de tous les types d’entrée de hook. Le type réel dépend du champ hook_event_name.

BaseHookInput

Champs de base présents dans tous les types d’entrée de hook.

PreToolUseHookInput

Données d’entrée pour les événements de hook PreToolUse.

PostToolUseHookInput

Données d’entrée pour les événements de hook PostToolUse.

PostToolUseFailureHookInput

Données d’entrée pour les événements de hook PostToolUseFailure. Appelé quand l’exécution d’un outil échoue.

UserPromptSubmitHookInput

Données d’entrée pour les événements de hook UserPromptSubmit.

StopHookInput

Données d’entrée pour les événements de hook Stop.

SubagentStopHookInput

Données d’entrée pour les événements de hook SubagentStop.

PreCompactHookInput

Données d’entrée pour les événements de hook PreCompact.

NotificationHookInput

Données d’entrée pour les événements de hook Notification.

SubagentStartHookInput

Données d’entrée pour les événements de hook SubagentStart.

PermissionRequestHookInput

Données d’entrée pour les événements de hook PermissionRequest. Permet aux hooks de gérer les décisions de permission programmatiquement.

HookJSONOutput

Type union pour les valeurs de retour de callback de hook.

SyncHookJSONOutput

Sortie de hook synchrone avec champs de contrôle et de décision.
Utilisez continue_ (avec trait de soulignement) dans le code Python. Il est automatiquement converti en continue quand envoyé au CLI.

HookSpecificOutput

Un TypedDict contenant le nom d’événement de hook et les champs spécifiques à l’événement. La forme dépend de la valeur hookEventName. Pour les détails complets sur les champs disponibles par événement de hook, voir Contrôler l’exécution avec les hooks. Une union discriminée de types de sortie spécifiques à l’événement. Le champ hookEventName détermine quels champs sont valides.

AsyncHookJSONOutput

Sortie de hook asynchrone qui diffère l’exécution du hook.
Utilisez async_ (avec trait de soulignement) dans le code Python. Il est automatiquement converti en async quand envoyé au CLI.

Exemple d’utilisation de hook

Cet exemple enregistre deux hooks : l’un qui bloque les commandes bash dangereuses comme rm -rf /, et un autre qui enregistre toute l’utilisation d’outils pour l’audit. Le hook de sécurité s’exécute uniquement sur les commandes Bash (via le matcher), tandis que le hook de journalisation s’exécute sur tous les outils.

Types d’entrée/sortie d’outil

Documentation des schémas d’entrée/sortie pour tous les outils Claude Code intégrés. Bien que le SDK Python n’exporte pas ceux-ci en tant que types, ils représentent la structure des entrées et sorties d’outils dans les messages.

Agent

Nom de l’outil : Agent (précédemment Task, qui est toujours accepté comme alias) Entrée :
Sortie :

AskUserQuestion

Nom de l’outil : AskUserQuestion Pose des questions de clarification à l’utilisateur pendant l’exécution. Voir Gérer les approbations et les entrées utilisateur pour les détails d’utilisation. Entrée :
Sortie :

Bash

Nom de l’outil : Bash Entrée :
Sortie :

Monitor

Nom de l’outil : Monitor Exécute une source de fond et livre chaque événement à Claude pour qu’il puisse réagir sans interrogation : command exécute un script et émet un événement par ligne stdout, et ws ouvre une WebSocket et émet un événement par trame texte. Fournissez exactement l’un de command ou ws. Lorsque Monitor exécute une commande, il suit les mêmes règles de permission que Bash ; une surveillance WebSocket demande une approbation séparément. La source ws nécessite Claude Code v2.1.195 ou ultérieur. Voir la référence de l’outil Monitor pour le comportement et la disponibilité du fournisseur. Entrée :
Sortie :

Edit

Nom de l’outil : Edit Entrée :
Sortie :

Read

Nom de l’outil : Read Entrée :
Sortie (fichiers texte) :
Sortie (images) :

Write

Nom de l’outil : Write Entrée :
Sortie :

Glob

Nom de l’outil : Glob Entrée :
Sortie :

Grep

Nom de l’outil : Grep Entrée :
Sortie (mode contenu) :
Sortie (mode fichiers_avec_correspondances) :

NotebookEdit

Nom de l’outil : NotebookEdit Entrée :
Sortie :

WebFetch

Nom de l’outil : WebFetch Entrée :
Sortie :

WebSearch

Nom de l’outil : WebSearch Entrée :
Sortie :

TodoWrite

Nom de l’outil : TodoWrite
À partir de Claude Code v2.1.142, TodoWrite est désactivé par défaut. Utilisez TaskCreate, TaskGet, TaskUpdate et TaskList à la place. Voir Migrer vers les outils Task pour mettre à jour votre code de surveillance, ou définissez CLAUDE_CODE_ENABLE_TASKS=0 pour revenir à TodoWrite.
Entrée :
Sortie :

TaskCreate

Nom de l’outil : TaskCreate Entrée :
Sortie :

TaskUpdate

Nom de l’outil : TaskUpdate Entrée :
Sortie :

TaskGet

Nom de l’outil : TaskGet Entrée :
Sortie :

TaskList

Nom de l’outil : TaskList Entrée :
Sortie :

BashOutput

Nom de l’outil : BashOutput Entrée :
Sortie :

KillBash

Nom de l’outil : KillBash Entrée :
Sortie :

ExitPlanMode

Nom de l’outil : ExitPlanMode Entrée :
Sortie :

ListMcpResources

Nom de l’outil : ListMcpResourcesTool Entrée :
Sortie :

ReadMcpResource

Nom de l’outil : ReadMcpResourceTool Entrée :
Sortie :

Fonctionnalités avancées avec ClaudeSDKClient

Construire une interface de conversation continue

Utiliser les hooks pour la modification du comportement

Surveillance de la progression en temps réel

Exemple d’utilisation

Opérations de fichiers de base (utilisant query)

Gestion des erreurs

Mode streaming avec client

Utiliser les outils personnalisés avec ClaudeSDKClient

Configuration du sandbox

SandboxSettings

Configuration pour le comportement du sandbox. Utilisez ceci pour activer le sandboxing des commandes et configurer les restrictions réseau programmatiquement.
Le sandbox dépend du support de la plateforme et, sur Linux, d’outils comme bubblewrap et socat. Par défaut, quand enabled est True mais que le sandbox ne peut pas démarrer, les commandes s’exécutent sans sandbox avec un avertissement sur stderr. Ce comportement par défaut diffère du SDK TypeScript, où failIfUnavailable est par défaut true.Définissez "failIfUnavailable": True dans vos paramètres de sandbox pour arrêter à la place. La clé n’est pas encore déclarée sur SandboxSettings, mais le SDK la transmet à Claude Code, qui la respecte. query() rapporte alors un ResultMessage avec subtype="error_during_execution" et la raison dans errors. Surveillez ce sous-type plutôt que de vous attendre à ce que query() lève une exception avant de produire des messages.

Exemple d’utilisation

Sécurité des sockets Unix : L’option allowUnixSockets peut accorder l’accès à des services système puissants. Par exemple, permettre /var/run/docker.sock accorde effectivement un accès complet au système hôte via l’API Docker, contournant l’isolation du sandbox. Autorisez uniquement les sockets Unix strictement nécessaires et comprenez les implications de sécurité de chacun.

SandboxNetworkConfig

Configuration spécifique au réseau pour le mode sandbox. Ces paramètres s’appliquent aux commandes Bash en sandbox quand enabled est True dans le parent SandboxSettings. Ils ne restreignent pas l’outil WebFetch, qui utilise à la place des règles de permission.
Le proxy sandbox intégré applique la liste blanche réseau en fonction du nom d’hôte demandé et ne termine pas ou n’inspecte pas le trafic TLS, donc des techniques telles que le domain fronting peuvent potentiellement le contourner. Voir Limitations de sécurité du sandboxing pour les détails et Déploiement sécurisé pour configurer un proxy qui termine TLS.

SandboxIgnoreViolations

Configuration pour ignorer les violations de sandbox spécifiques.

Fallback de permissions pour les commandes sans sandbox

Quand allowUnsandboxedCommands est activé, le modèle peut demander l’exécution de commandes en dehors du sandbox en définissant dangerouslyDisableSandbox: True dans l’entrée d’outil. Ces requêtes reviennent au système de permissions existant, ce qui signifie que votre gestionnaire can_use_tool sera invoqué, vous permettant d’implémenter une logique d’autorisation personnalisée.
excludedCommands vs allowUnsandboxedCommands :
  • excludedCommands : Une liste statique de commandes qui contournent toujours le sandbox automatiquement (par exemple, ["docker"]). Le modèle n’a aucun contrôle sur ceci.
  • allowUnsandboxedCommands : Permet au modèle de décider à l’exécution s’il faut demander l’exécution sans sandbox en définissant dangerouslyDisableSandbox: True dans l’entrée d’outil.
Ce modèle vous permet de :
  • Auditer les requêtes du modèle : Enregistrez quand le modèle demande l’exécution sans sandbox
  • Implémenter des listes blanches : Autorisez uniquement des commandes spécifiques à s’exécuter sans sandbox
  • Ajouter des flux d’approbation : Nécessitez une autorisation explicite pour les opérations privilégiées
Les commandes s’exécutant avec dangerouslyDisableSandbox: True ont un accès complet au système. Assurez-vous que votre gestionnaire can_use_tool valide ces requêtes avec soin.Si permission_mode est défini sur bypassPermissions et allow_unsandboxed_commands est activé, le modèle peut exécuter de manière autonome des commandes en dehors du sandbox sans aucun prompt d’approbation. Cette combinaison permet effectivement au modèle d’échapper à l’isolation du sandbox silencieusement.

Voir aussi