En-têtes dynamiques

Pour les environnements d'entreprise qui nécessitent une authentification dynamique, vous pouvez configurer un script pour générer des en-têtes dynamiquement. Les en-têtes dynamiques s'appliquent uniquement aux protocoles http/protobuf et http/json. Avec le protocole grpc, Claude Code utilise uniquement les variables d'en-têtes statiques, OTEL_EXPORTER_OTLP_HEADERS et ses variantes spécifiques au signal.

Configuration des paramètres

Ajoutez à votre .claude/settings.json, en remplaçant le chemin par votre propre script :

{
  "otelHeadersHelper": "/path/to/generate-otel-headers.sh"
}

La valeur peut être le chemin d'un fichier exécutable, y compris un chemin contenant des espaces, ou une ligne de commande shell avec des arguments. Sur Windows, la valeur s'exécute toujours via le shell, donc mettez entre guillemets un chemin contenant des espaces à l'intérieur de la valeur JSON.

Exigences du script

Le script doit produire un JSON valide avec des paires clé-valeur de chaîne représentant les en-têtes HTTP :

#!/bin/bash
# Example: Multiple headers
echo "{\"Authorization\": \"Bearer $(get-token.sh)\", \"X-API-Key\": \"$(get-api-key.sh)\"}"

Si l'assistant échoue ou imprime une sortie qui ne répond pas à ces exigences, les exports échouent et votre backend de télémétrie ne reçoit rien de la session jusqu'à ce que l'assistant fonctionne à nouveau. Claude Code signale l'échec dans :

• Une notification d'avertissement dans les sessions interactives, otelHeadersHelper failed; telemetry is not being exported, affichée une fois par session lorsque l'assistant échoue pour la première fois
• Sortie /status
• Le journal de débogage, lors de l'exécution avec --debug ou après l'exécution de /debug dans la session
• stderr, dans les sessions non interactives démarrées avec -p

Comportement d'actualisation

Le script d'assistant d'en-têtes s'exécute au démarrage et périodiquement par la suite pour prendre en charge l'actualisation des jetons. Par défaut, le script s'exécute toutes les 29 minutes. Personnalisez l'intervalle avec la variable d'environnement CLAUDE_CODE_OTEL_HEADERS_HELPER_DEBOUNCE_MS.

Support des organisations multi-équipes

Les organisations avec plusieurs équipes ou départements peuvent ajouter des attributs personnalisés pour distinguer les différents groupes en utilisant la variable d'environnement OTEL_RESOURCE_ATTRIBUTES :

# Add custom attributes for team identification
export OTEL_RESOURCE_ATTRIBUTES="department=engineering,team.id=platform,cost_center=eng-123"

Ces attributs personnalisés sont inclus dans toutes les métriques et événements, ce qui vous permet de :

• Filtrer les métriques par équipe ou département
• Suivre les coûts par centre de coûts
• Créer des tableaux de bord spécifiques à l'équipe
• Configurer des alertes pour des équipes spécifiques

Claude Code attache ces valeurs comme attributs sur chaque point de données de métrique et enregistrement d'événement, en plus de les envoyer dans le bloc de ressource OTLP. Parce que la plupart des backends de métriques exposent les attributs de point de données comme des étiquettes interrogeables, vous pouvez regrouper et filtrer les métriques par vos clés personnalisées directement. À l'exception des attributs de référentiel vcs.*, les clés personnalisées ne remplacent jamais les attributs standard tels que user.id ou session.id : lorsqu'une clé entre en collision, Claude Code conserve la valeur intégrée.

Chaque clé personnalisée devient une étiquette sur chaque série de métriques, donc les valeurs de cardinalité élevée augmentent le coût de stockage dans votre backend de métriques. Pour envoyer des attributs personnalisés dans le bloc de ressource uniquement et les omettre des étiquettes de point de données, définissez OTEL_METRICS_INCLUDE_RESOURCE_ATTRIBUTES=false. Voir Contrôle de la cardinalité des métriques.

Exemples de configurations

Définissez ces variables d'environnement avant d'exécuter claude. Chaque scénario ci-dessous montre une configuration complète, et chaque variable est décrite sous Variables de configuration communes. Pour confirmer qu'une configuration a pris effet, vérifiez votre backend pour la métrique claude_code.session.count après le démarrage d'une session ; le Démarrage rapide couvre la vérification en logs uniquement et ce qu'il faut vérifier lorsque rien n'arrive.

Pour le débogage de console avec un intervalle d'export d'une seconde :

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=console
export OTEL_METRIC_EXPORT_INTERVAL=1000

Pour OTLP sur gRPC :

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317

Pour Prometheus, récupéré à partir de http://localhost:9464/metrics :

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=prometheus

Sur un environnement auto-hébergé, la session lie le port 9464 uniquement à la capacité par défaut du runner d'une. À une capacité plus élevée, le runner réexpose les compteurs et jauges de session sur son propre point de terminaison /metrics à la place.

Pour envoyer des métriques à plusieurs exportateurs :

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=console,otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=http/json

Pour envoyer des métriques et des journaux à différents points de terminaison ou backends :

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_METRICS_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=http://metrics.example.com:4318
export OTEL_EXPORTER_OTLP_LOGS_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=http://logs.example.com:4317

Pour exporter uniquement les métriques, sans événements ni journaux :

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317

Pour exporter uniquement les événements et journaux, sans métriques :

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317

Télémétrie des sessions cloud et Claude Tag

Les sessions cloud, y compris les sessions du canal Claude Tag, s'exécutent dans des environnements cloud plutôt que sur les appareils de vos utilisateurs, donc un fichier de paramètres gérés ou un profil shell sur ces appareils ne configure pas leur télémétrie. Pour les sessions dans les environnements hébergés par Anthropic, cette section couvre l'endroit où définir les variables de télémétrie, comment rendre votre collecteur accessible à partir de l'environnement, et comment distinguer les sessions cloud et Claude Tag dans les données exportées.

Pour exporter la télémétrie de ces sessions, définissez CLAUDE_CODE_ENABLE_TELEMETRY et les variables OTEL_*, en utilisant les mêmes clés que l'exemple de configuration administrateur, dans l'un des deux endroits suivants :

• Paramètres gérés par le serveur : ajoutez-les au bloc env des paramètres gérés par le serveur de votre organisation. Claude Code récupère ces paramètres au démarrage partout où les paramètres gérés par le serveur s'appliquent, ce qui inclut les machines de vos utilisateurs et les sessions cloud autres que les sessions du canal Claude Tag. Les sessions Claude Tag ne reçoivent pas vos paramètres gérés par le serveur, donc cette route ne les configure pas.
• Les variables de l'environnement : ajoutez-les aux variables d'environnement d'un environnement cloud pour configurer uniquement les sessions qui s'exécutent dans cet environnement. C'est la route qui atteint les sessions Claude Tag.

Quiconque utilise un environnement peut lire ses variables, donc ne mettez pas une credential là, comme un jeton de collecteur dans OTEL_EXPORTER_OTLP_HEADERS. Une credential API sur l'environnement n'aide pas non plus, car l'export de télémétrie propre de Claude Code est l'une des requêtes qui ne reçoivent jamais la credential. Si votre collecteur nécessite une credential, configurez l'export entier via les paramètres gérés par le serveur à la place, car lorsque vous définissez une credential là, Claude Code supprime les variables de point de terminaison définies en dehors des paramètres gérés.

Gardez ces contraintes à l'esprit lorsque vous configurez la télémétrie pour les sessions cloud :

• Laissez les sessions atteindre le collecteur : Claude Code envoie l'export via le réseau de la session, donc si elle atteint l'hôte dans votre OTEL_EXPORTER_OTLP_ENDPOINT dépend du niveau d'accès réseau de l'environnement. Si les sessions ne peuvent pas atteindre le domaine du collecteur au niveau que vous avez choisi, ajoutez le domaine à la liste d'autorisation de l'environnement, car aucun paramètre géré par le serveur n'ajoute de domaines à la liste d'autorisation réseau d'un environnement.
• Les canaux Claude Tag utilisent des environnements au niveau de l'organisation : les sessions de canal s'exécutent dans des environnements au niveau de l'organisation plutôt que dans les environnements personnels des membres, donc effectuez les modifications de la liste d'autorisation et des variables d'environnement sur l'environnement partagé défini comme défaut de votre organisation ou épinglé au canal.
• Cowork est configuré séparément : les sessions Cowork ne reçoivent pas les paramètres gérés par le serveur, comme le montre le tableau de couverture de surface, donc le bloc env géré par le serveur ne configure pas leur télémétrie.

Attribuer la télémétrie aux sessions cloud

Par défaut, les métriques et les événements d'une session cloud portent les attributs standard, y compris session.id, ccr.session.id, et organization.id, afin que vous puissiez filtrer par session ou organisation sans configuration supplémentaire. La valeur ccr.session.id est le CLAUDE_CODE_REMOTE_SESSION_ID de la session. Pour le transformer en URL de transcription de la session, voir Lier la sortie à la session.

Pour attribuer la télémétrie plus en détail, utilisez ces options :

• Identifier les sessions Claude Tag : définissez OTEL_METRICS_INCLUDE_ENTRYPOINT=true, comme décrit sous Contrôle de la cardinalité des métriques. Les métriques portent alors app.entrypoint, dont la valeur est claude-in-slack pour les sessions Claude Tag.
• Ajouter des attributs personnalisés : définissez OTEL_RESOURCE_ATTRIBUTES au même endroit où vous définissez les autres variables OTEL_* pour ces sessions. Si vous l'export dans le script de configuration de l'environnement à la place, la valeur n'atteint pas Claude Code : le script de configuration est un script Bash séparé qui s'exécute avant le lancement de Claude Code, et les variables qu'il exporte se terminent avec lui.

Dans les sessions du canal Claude Tag, Claude fonctionne comme l'identité partagée de votre organisation plutôt que comme n'importe quel membre, donc ne vous fiez pas aux attributs user.* pour identifier qui a tagué Claude.

Métriques et événements disponibles

Attributs standard

Toutes les métriques et tous les événements partagent ces attributs standard :

Dans les sessions connectées à une passerelle d'applications Claude via /login, la CLI marque les exports avec l'identité authentifiée : user.id correspond au sujet de l'IdP, user.email à l'adresse e-mail connectée, et user.groups contient l'appartenance aux groupes de l'IdP sous forme de chaîne séparée par des virgules. Chaque export contient également identity.source: gateway-oidc. L'identité de la passerelle est appliquée en dernier, de sorte que les clés user.* et identity.* définies via OTEL_RESOURCE_ATTRIBUTES sont ignorées dans ces sessions.

Pour les attributs d'identité des sessions Claude Desktop et Cowork qui se connectent via une passerelle, consultez la référence telemetry de la passerelle.

Les événements incluent en plus les attributs suivants. Ceux-ci ne sont jamais attachés aux métriques, car ils entraîneraient une cardinalité non bornée :

• prompt.id : UUID corrélant un prompt utilisateur avec tous les événements suivants jusqu'au prompt suivant. Consultez Attributs de corrélation des événements.
• workspace.host_paths : répertoires de l'espace de travail hôte sélectionnés dans l'application de bureau, sous forme de tableau de chaînes
• workflow.run_id : identifiant d'exécution, préfixé par wf_, présent sur les événements d'API et d'outil émis par les agents appartenant à une exécution de l'outil Workflow. Filtrer les événements sur un workflow.run_id permet de reconstituer les requêtes API et les résultats d'outils de cette exécution. L'identifiant couvre les agents lancés par le script du workflow ainsi que tous les agents que ceux-ci lancent à leur tour, comme les invocations de skills. Il correspond à l'identifiant d'exécution indiqué dans le résultat de l'outil Workflow. Absent de tous les autres événements. Nécessite Claude Code v2.1.202 ou ultérieur
• workflow.name : nom du workflow, c'est-à-dire le meta.name de son script, émis avec workflow.run_id. Les noms des workflows intégrés apparaissent tels quels lorsque l'exécution utilise le script intégré non modifié. Les noms définis par l'utilisateur, y compris les copies modifiées de scripts intégrés, sont remplacés par custom sauf si OTEL_LOG_TOOL_DETAILS=1 est défini. Nécessite Claude Code v2.1.202 ou ultérieur

Attributs de dépôt

Définissez OTEL_METRICS_INCLUDE_REPOSITORY=true pour étiqueter les métriques et les événements avec l'identité du dépôt de la session, afin qu'un collecteur partagé puisse attribuer l'utilisation par dépôt. Nécessite Claude Code v2.1.269 ou ultérieur.

Claude Code dérive ces attributs une fois par session à partir du remote origin du dépôt. Lorsque les remotes HTTPS et SSH d'un dépôt désignent le même hôte et le même chemin, comme c'est le cas sur GitHub, GitLab et Bitbucket Cloud, tous deux produisent des valeurs identiques :

Les valeurs sont mises en minuscules, et les identifiants, chaînes de requête et fragments de l'URL du remote n'y apparaissent jamais. Les attributs sont omis lorsque la session n'a pas de remote origin, lorsque le remote n'a pas la forme d'une URL, ou lorsque le seul dépôt englobant est votre répertoire personnel.

Pour obtenir ces attributs depuis une session cloud, définissez les variables de télémétrie, y compris OTEL_METRICS_INCLUDE_REPOSITORY, dans son environnement cloud. Autorisez également le domaine de votre collecteur dans l'accès réseau de l'environnement.

Une clé vcs.* que vous déclarez dans OTEL_RESOURCE_ATTRIBUTES remplace la valeur dérivée pour cette clé. Si vous déclarez vcs.repository.url.full, Claude Code ne lit jamais le remote et ne rapporte que les clés que vous déclarez.

Si les clones HTTPS et SSH d'un même dépôt rapportent des valeurs différentes, par exemple sur une installation auto-hébergée dont l'URL de clonage HTTPS comporte un préfixe de chemin absent de l'URL SSH, déclarez vcs.repository.url.full dans OTEL_RESOURCE_ATTRIBUTES ainsi que toutes les autres clés vcs.* que vous souhaitez voir rapportées. Chaque clone rapporte alors l'identité que vous déclarez.

Les attributs sont transmis uniquement à vos propres exportateurs ; la télémétrie d'Anthropic supprime toutes les clés vcs.*.

Métriques

Claude Code exporte les métriques suivantes. La colonne Unité indique la chaîne d'unité OpenTelemetry attachée à chaque métrique ; les métriques de comptage n'en ont pas.

Lorsque prometheus est le seul exportateur indiqué dans OTEL_METRICS_EXPORTER, Claude Code omet les unités USD, tokens et s des métriques exportées afin que le scrape reste au format texte Prometheus valide. Les noms des métriques ne changent pas, et les configurations qui combinent plusieurs exportateurs, comme otlp,prometheus, conservent les unités. Avant la v2.1.216, le scrape Prometheus incluait des lignes # UNIT propres à OpenMetrics que certains scrapers rejetaient.

Détails des métriques

Chaque métrique inclut les attributs standard listés ci-dessus. Les métriques dotées d'attributs supplémentaires propres à leur contexte sont indiquées ci-dessous.

Compteur de sessions

Incrémenté au début de chaque session.

Attributs :

• Tous les attributs standard
• start_type : mode de démarrage de la session. L'une des valeurs "fresh", "resume", "continue" ou "agents_view". La valeur "agents_view" identifie le processus du tableau de bord claude agents, une interface locale lancée par l'utilisateur plutôt qu'une session conversationnelle. Filtrez sur cette valeur pour distinguer, dans vos tableaux de bord, les lancements de processus d'interface des sessions conversationnelles.

Compteur de lignes de code

Incrémenté lorsque du code est ajouté ou supprimé.

Attributs :

• Tous les attributs standard
• type : ("added", "removed")
• model : identifiant du modèle ayant effectué la modification (par exemple, "claude-sonnet-5")

Compteur de pull requests

Incrémenté lorsque Claude Code crée une pull request ou une merge request via une commande shell ou un outil MCP.

Attributs :

• Tous les attributs standard

Compteur de commits

Incrémenté lors de la création de commits git via Claude Code.

Attributs :

• Tous les attributs standard

Compteur de coûts

Incrémenté après chaque requête API.

Les attributs agent.name, skill.name, plugin.name, mcp_server.name et mcp_tool.name masquent chacun par défaut certains noms en les remplaçant par l'espace réservé "custom" ou "third-party". Si vous définissez OTEL_LOG_TOOL_DETAILS=1, ils contiennent les noms réels. Avant la v2.1.273, les compteurs de coûts et de tokens ainsi que les événements api_request, api_error et api_refusal contenaient les valeurs masquées même lorsque OTEL_LOG_TOOL_DETAILS=1 était défini.

Attributs :

• Tous les attributs standard
• model : identifiant du modèle (par exemple, "claude-sonnet-5")
• query_source : catégorie du sous-système ayant émis la requête. L'une des valeurs "main", "subagent" ou "auxiliary"
• speed : "fast" lorsque la requête a utilisé le mode rapide. Absent sinon
• effort : niveau d'effort appliqué à la requête : "low", "medium", "high", "xhigh" ou "max". Absent lorsque Claude Code n'envoie aucun niveau d'effort, par exemple avec un modèle qui ne prend pas en charge l'effort.
• agent.name : type de sous-agent ayant émis la requête. Les noms des agents intégrés et des agents provenant de plugins de la marketplace officielle apparaissent tels quels. Les autres noms d'agents définis par l'utilisateur sont remplacés par "custom". Absent lorsque la requête n'a pas été émise par un type de sous-agent nommé.
• skill.name : skill actif pour la requête, défini par l'outil Skill ou par une commande /, ou hérité par un sous-agent lancé. Les noms des skills intégrés, fournis, définis par l'utilisateur et issus de plugins de la marketplace officielle apparaissent tels quels. Les noms des skills de plugins tiers sont remplacés par "third-party". Absent lorsqu'aucun skill n'est actif.
• plugin.name : plugin propriétaire lorsque le skill ou le sous-agent actif est fourni par un plugin. Les noms des plugins de la marketplace officielle apparaissent tels quels. Les noms des plugins tiers sont remplacés par "third-party". Absent lorsque ni le skill ni le sous-agent n'a de plugin propriétaire.
• marketplace.name : marketplace depuis laquelle le plugin propriétaire a été installé. Émis uniquement pour les plugins de la marketplace officielle, même lorsque OTEL_LOG_TOOL_DETAILS=1 est défini. Absent sinon.
• mcp_server.name : serveur MCP dont cette requête a consommé le résultat d'outil. Les noms des serveurs intégrés, relayés par claude.ai et du registre officiel apparaissent tels quels. Les noms des serveurs configurés par l'utilisateur sont remplacés par "custom". Absent lorsque la requête n'a consommé aucun résultat d'outil MCP. Avant la v2.1.222, Claude Code définissait cet attribut sur chaque requête suivant un appel d'outil MCP, et pas uniquement sur les requêtes ayant consommé un résultat d'outil ; les tableaux de bord qui l'agrègent affichent donc une baisse après la mise à jour.
• mcp_tool.name : outil MCP dont cette requête a consommé le résultat, avec le même comportement de masquage et de version que mcp_server.name. Absent lorsque la requête n'a consommé aucun résultat d'outil MCP.

Compteur de tokens

Incrémenté après chaque requête API.

Attributs :

• Tous les attributs standard
• type : ("input", "output", "cacheRead", "cacheCreation"). Le type "input" exclut les tokens lus depuis le cache de prompts ou écrits dans celui-ci, qui sont comptabilisés sous "cacheRead" et "cacheCreation"
• model : identifiant du modèle (par exemple, "claude-sonnet-5")
• query_source : catégorie du sous-système ayant émis la requête. L'une des valeurs "main", "subagent" ou "auxiliary"
• speed : "fast" lorsque la requête a utilisé le mode rapide. Absent sinon
• effort : niveau d'effort appliqué à la requête. Consultez Compteur de coûts pour plus de détails.
• agent.name, skill.name, plugin.name, marketplace.name, mcp_server.name, mcp_tool.name : attribution de la requête au skill, au plugin, à l'agent et à MCP. Consultez Compteur de coûts pour les définitions et le comportement de masquage.

Compteur de décisions des outils d'édition de code

Incrémenté lorsque l'utilisateur accepte ou refuse l'utilisation des outils Edit, Write ou NotebookEdit.

Attributs :

• Tous les attributs standard
• tool_name : nom de l'outil ("Edit", "Write", "NotebookEdit")
• decision : décision de l'utilisateur ("accept", "reject")
• source : origine de la décision. L'une des valeurs "config", "hook", "user_permanent", "user_temporary", "user_abort" ou "user_reject". Consultez l'événement de décision d'outil pour la signification de chaque valeur.
• language : langage de programmation du fichier modifié, par exemple "TypeScript", "Python", "JavaScript" ou "Markdown". Renvoie "unknown" pour les extensions de fichier non reconnues.

Compteur de temps actif

Mesure le temps réellement passé à utiliser activement Claude Code, hors temps d'inactivité. Cette métrique est incrémentée pendant les interactions de l'utilisateur, comme la saisie et la lecture des réponses, ainsi que pendant le traitement par la CLI, comme l'exécution des outils et la génération des réponses de l'IA.

Attributs :

• Tous les attributs standard
• type : "user" pour les interactions au clavier, "cli" pour l'exécution des outils et les réponses de l'IA

Événements

Claude Code exporte les événements suivants via les logs/événements OpenTelemetry (lorsque OTEL_LOGS_EXPORTER est configuré) :

Attributs de corrélation des événements

Lorsqu'un utilisateur soumet un prompt, Claude Code peut effectuer plusieurs appels API et exécuter plusieurs outils. L'attribut prompt.id vous permet de rattacher tous ces événements au prompt unique qui les a déclenchés.

Pour retracer toute l'activité déclenchée par un même prompt, filtrez vos événements sur une valeur prompt.id spécifique. Vous obtenez ainsi l'événement user_prompt, les éventuels événements api_request et les éventuels événements tool_result survenus pendant le traitement de ce prompt.

event.sequence commence à 0 à chaque démarrage d'un processus Claude Code et s'incrémente pendant toute la durée de vie de ce processus. Il continue de s'incrémenter après /clear, qui attribue un nouveau session.id. Si vous reprenez une session sans la dupliquer, la session conserve son session.id mais tire ses valeurs event.sequence du processus qui l'a reprise ; au sein d'une même session, un événement ultérieur peut donc porter une valeur inférieure à celle d'un événement antérieur, ou la répéter. Pour ordonner les événements d'une session, triez-les par event.timestamp et utilisez event.sequence pour ordonner les événements qui partagent un même horodatage.

Pour une reconstitution au niveau des messages, chaque classe d'événements porte une clé correspondant à un champ de la transcription de la session. Le format des entrées de transcription est interne à Claude Code et change d'une version à l'autre ; un pipeline qui effectue des jointures sur ces champs peut donc cesser de fonctionner à n'importe quelle version. Considérez ces jointures comme propres à une version plutôt que comme un contrat stable :

• message.uuid sur user_prompt, assistant_response et api_response_body
• request_id sur les événements d'API, conservé sous le nom requestId dans les entrées assistant de la transcription
• tool_use_id sur les événements tool_result et tool_decision

Événement de prompt utilisateur

Journalisé lorsqu'un utilisateur soumet un prompt.

Nom de l'événement : claude_code.user_prompt

Attributs :

• Tous les attributs standard
• event.name : "user_prompt"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• prompt_length : longueur du prompt
• prompt : contenu du prompt. Masqué par défaut. Définissez OTEL_LOG_USER_PROMPTS=1 pour l'inclure
• message.uuid : UUID du message utilisateur résultant, correspondant à l'entrée de transcription conservée. Absent pour les envois de commandes, qui peuvent produire zéro ou plusieurs messages. Nécessite Claude Code v2.1.214 ou ultérieur
• command_name : nom de la commande lorsque le prompt en invoque une. Les noms des commandes intégrées et fournies, comme compact ou debug, sont émis tels quels ; les alias comme reset sont émis tels que saisis plutôt que sous leur nom canonique. Les noms des commandes personnalisées, de plugins et MCP sont ramenés à custom ou mcp, sauf si OTEL_LOG_TOOL_DETAILS=1 est défini
• command_source : origine de la commande lorsqu'elle est présente : builtin, custom ou mcp. Les commandes fournies par des plugins sont signalées comme custom

Événement de réponse de l'assistant

Journalisé après chaque requête API qui renvoie du contenu textuel de la part du modèle. Seuls les blocs de texte de la réponse sont inclus ; les blocs de réflexion et d'utilisation d'outils sont exclus. Nécessite Claude Code v2.1.193 ou ultérieur.

Nom de l'événement : claude_code.assistant_response

Attributs :

• Tous les attributs standard
• event.name : "assistant_response"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• response_length : longueur du texte de la réponse en caractères
• response : texte de la réponse, tronqué à la limite de contenu (60 Ko par défaut). Masqué en <REDACTED> par défaut. Définissez OTEL_LOG_ASSISTANT_RESPONSES=1 pour l'inclure. Lorsque OTEL_LOG_ASSISTANT_RESPONSES n'est pas défini, c'est OTEL_LOG_USER_PROMPTS qui le contrôle ; définissez donc OTEL_LOG_ASSISTANT_RESPONSES=0 pour garder les réponses masquées lorsque la journalisation des prompts est activée
• model : identifiant du modèle (par exemple, "claude-sonnet-5")
• request_id : ID de la requête API, décrit dans Attributs de corrélation des événements
• message.uuid : UUID de la dernière entrée de transcription de la réponse. Une réponse de l'API est conservée sous la forme d'une entrée de transcription par bloc de contenu ; il s'agit de la dernière, à laquelle se rattache le parentUuid du tour suivant. Nécessite Claude Code v2.1.214 ou ultérieur
• query_source : sous-système ayant émis la requête, par exemple "repl_main_thread", "compact" ou le nom d'un sous-agent

Événement de résultat d'outil

Journalisé lorsqu'un outil termine son exécution. Non émis si l'appel d'outil a été refusé ; consultez l'événement de décision d'outil pour les refus.

Nom de l'événement : claude_code.tool_result

Attributs :

• Tous les attributs standard
• event.name : "tool_result"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• tool_name : nom de l'outil
• tool_use_id : identifiant unique de cette invocation d'outil. Correspond au tool_use_id transmis aux hooks, ce qui permet de corréler les événements OTel avec les données capturées par les hooks.
• success : "true" ou "false"
• duration_ms : durée d'exécution en millisecondes
• error_type : chaîne de catégorie d'erreur lorsque l'outil a échoué, par exemple "Error:ENOENT" ou "ShellError"
• error (lorsque OTEL_LOG_TOOL_DETAILS=1) : message d'erreur complet lorsque l'outil a échoué
• decision_type : toujours "accept", puisque cet événement n'est émis qu'après l'exécution de l'outil. Les appels refusés ne produisent pas de résultat d'outil
• decision_source : origine de la décision de permission. L'une des valeurs "config", "hook", "user_permanent" ou "user_temporary". Consultez l'événement de décision d'outil pour la signification de chaque valeur. Les sources propres aux refus, "user_abort" et "user_reject", n'apparaissent jamais sur cet événement.
• tool_input_size_bytes : taille en octets de l'entrée de l'outil sérialisée en JSON
• tool_result_size_bytes : taille en octets du résultat de l'outil
• mcp_server_scope : identifiant de portée du serveur MCP (pour les outils MCP)
• vcs.ref.head.revision, vcs.ref.head.name, vcs.ref.head.type (lorsque OTEL_LOG_TOOL_DETAILS=1) : identité du commit d'un git commit réussi exécuté par l'outil Bash ou PowerShell. vcs.ref.head.revision est le SHA du commit, vcs.ref.head.name est la branche sur laquelle il a été créé et vcs.ref.head.type vaut branch. Le nom et le type sont omis lorsque le commit a été créé sur une HEAD détachée. Nécessite Claude Code v2.1.269 ou ultérieur
• tool_parameters (lorsque OTEL_LOG_TOOL_DETAILS=1) : chaîne JSON contenant les paramètres propres à l'outil. Pour les serveurs intégrés de Claude Desktop, dans les sessions dont Claude Desktop est propriétaire, la paire mcp_server_name/mcp_tool_name est incluse même lorsque le flag est désactivé, selon la même exception liée à l'hôte que pour l'événement de décision d'outil, ce qui nécessite Claude Code v2.1.214 ou ultérieur. Les paramètres varient selon l'outil :
  • Pour l'outil Bash : inclut bash_command, full_command, timeout, description et dangerouslyDisableSandbox, ainsi que git_commit_id et git_branch lorsqu'une commande git commit réussit. git_commit_id est le SHA complet du commit lorsque celui-ci est la HEAD du répertoire de travail de la session, et le SHA abrégé de git sinon. git_branch est la branche sur laquelle il a été créé, omise sur une HEAD détachée
  • Pour l'outil Bash de l'espace de travail de l'application de bureau, qui signale également tool_name comme Bash : inclut uniquement bash_command, full_command et timeout
  • Pour les outils MCP : inclut mcp_server_name, mcp_tool_name
  • Pour l'outil Skill : inclut skill_name
  • Pour l'outil Agent ou l'ancien outil Task : inclut subagent_type
• tool_input (lorsque OTEL_LOG_TOOL_DETAILS=1) : arguments de l'outil sérialisés en JSON. Les valeurs individuelles de plus de 512 caractères sont tronquées, et le payload complet est limité à ~4 K caractères. S'applique à tous les outils, y compris les outils MCP.

Événement de requête API

Journalisé pour chaque requête API envoyée à Claude.

Nom de l'événement : claude_code.api_request

Attributs :

• Tous les attributs standard
• event.name : "api_request"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• model : modèle utilisé (par exemple, "claude-sonnet-5")
• cost_usd : coût estimé en USD
• cost_usd_micros : coût estimé en millionièmes de dollar américain, émis sous forme d'entier
• duration_ms : durée de la requête en millisecondes
• input_tokens : nombre de tokens d'entrée, hors tokens lus depuis le cache de prompts ou écrits dans celui-ci
• output_tokens : nombre de tokens de sortie
• cache_read_tokens : nombre de tokens lus depuis le cache
• cache_creation_tokens : nombre de tokens utilisés pour la création du cache
• request_id : ID de la requête API, par exemple "req_011...", décrit dans Attributs de corrélation des événements.
• client_request_id : UUID généré par le client et envoyé dans l'en-tête de requête x-client-request-id ; consultez le tableau des attributs de corrélation des événements pour savoir quand il est présent. Nécessite Claude Code v2.1.214 ou ultérieur
• speed : "fast" ou "normal", indiquant si le mode rapide était actif
• query_source : sous-système ayant émis la requête, par exemple "repl_main_thread", "compact" ou le nom d'un sous-agent
• effort : niveau d'effort appliqué à la requête : "low", "medium", "high", "xhigh" ou "max". Absent lorsque Claude Code n'envoie aucun niveau d'effort, par exemple avec un modèle qui ne prend pas en charge l'effort.
• agent.name, skill.name, plugin.name, marketplace.name, mcp_server.name, mcp_tool.name : attribution de la requête au skill, au plugin, à l'agent et à MCP. Consultez Compteur de coûts pour les définitions et le comportement de masquage.

Événement d'erreur API

Journalisé lorsqu'une requête API envoyée à Claude échoue.

Nom de l'événement : claude_code.api_error

Attributs :

• Tous les attributs standard
• event.name : "api_error"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• model : modèle utilisé (par exemple, "claude-sonnet-5")
• error : message d'erreur
• status_code : code de statut HTTP sous forme de nombre. Absent pour les erreurs non HTTP, comme les échecs de connexion.
• duration_ms : durée de la requête en millisecondes
• attempt : nombre total de tentatives effectuées, y compris la requête initiale (1 signifie qu'aucune nouvelle tentative n'a eu lieu)
• request_id : ID de la requête API, par exemple "req_011...", décrit dans Attributs de corrélation des événements.
• client_request_id : UUID généré par le client et envoyé dans l'en-tête de requête x-client-request-id. Disponible même lorsqu'un échec, comme un délai d'expiration ou une erreur de connexion, n'a jamais produit de request_id côté serveur ; consultez le tableau des attributs de corrélation des événements pour savoir quand il est présent. Nécessite Claude Code v2.1.214 ou ultérieur
• speed : "fast" ou "normal", indiquant si le mode rapide était actif
• query_source : sous-système ayant émis la requête, par exemple "repl_main_thread", "compact" ou le nom d'un sous-agent
• effort : niveau d'effort appliqué à la requête. Absent lorsque Claude Code n'envoie aucun niveau d'effort, par exemple avec un modèle qui ne prend pas en charge l'effort.
• agent.name, skill.name, plugin.name, marketplace.name, mcp_server.name, mcp_tool.name : attribution de la requête au skill, au plugin, à l'agent et à MCP. Consultez Compteur de coûts pour les définitions et le comportement de masquage.

Événement de refus API

Journalisé lorsqu'une requête API renvoie stop_reason: "refusal". Les refus arrivent sur un flux de réponse réussi plutôt que sous forme d'erreur HTTP ; l'événement api_error ne se déclenche donc pas pour eux. Cet événement vous permet de suivre la fréquence des refus et de les regrouper selon les mêmes attributs que api_request et api_error.

Nom de l'événement : claude_code.api_refusal

Attributs :

• Tous les attributs standard
• event.name : "api_refusal"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• model : identifiant du modèle indiqué dans la requête
• request_id : ID de la requête API, par exemple "req_011...", décrit dans Attributs de corrélation des événements.
• query_source : sous-système ayant émis la requête, par exemple "repl_main_thread", "compact" ou le nom d'un sous-agent. Consultez api_request pour les définitions.
• speed : "fast" lorsque le mode rapide est actif, ou "normal"
• attempt : numéro de la tentative. La première tentative vaut 1.
• effort : niveau d'effort appliqué à la requête. Absent lorsque Claude Code n'envoie aucun niveau d'effort, par exemple avec un modèle qui ne prend pas en charge l'effort.
• server_fallback_hop : true lorsque le mécanisme de modèle de secours côté serveur de l'API a déjà réessayé ce refus sur un autre modèle, de sorte que l'utilisateur n'a pas vu ce refus en particulier. false lorsque la requête s'est terminée par un refus. Un même tour peut émettre à la fois un événement intermédiaire true et un événement final false ultérieur lorsque le modèle de secours refuse également.
• has_category : true lorsque la réponse de l'API contenait un stop_details.category valant "cyber", "bio", "frontier_llm" ou "reasoning_extraction". false lorsque la réponse ne contenait aucune catégorie ou une valeur hors de cet ensemble. Absent lorsque server_fallback_hop vaut true, car les blocs intermédiaires ne contiennent pas de stop_details.
• has_explanation : true lorsque la réponse de l'API contenait un stop_details.explanation, false sinon. Absent lorsque server_fallback_hop vaut true.
• category : valeur stop_details.category de la réponse de l'API. L'une des valeurs "cyber", "bio", "frontier_llm" ou "reasoning_extraction". Présent uniquement lorsque OTEL_LOG_TOOL_DETAILS=1 est défini et que has_category vaut true.
• agent.name, skill.name, plugin.name, marketplace.name, mcp_server.name, mcp_tool.name : attribution de la requête au skill, au plugin, à l'agent et à MCP. Consultez Compteur de coûts pour les définitions et le comportement de masquage.

Événement de corps de requête API

Journalisé pour chaque tentative de requête API lorsque OTEL_LOG_RAW_API_BODIES est défini. Un événement est émis par tentative ; chaque nouvelle tentative avec des paramètres ajustés produit donc son propre événement.

Nom de l'événement : claude_code.api_request_body

Attributs :

• Tous les attributs standard
• event.name : "api_request_body"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• body : paramètres de la requête de l'API Messages sérialisés en JSON, comme le prompt système, les messages et les outils, tronqués à la limite de contenu (60 Ko par défaut). Le contenu de réflexion étendue des tours précédents de l'assistant est masqué. Émis uniquement en mode inline (OTEL_LOG_RAW_API_BODIES=1).
• body_ref : chemin absolu vers un fichier <dir>/<uuid>.request.json contenant le corps non tronqué. Émis uniquement en mode fichier (OTEL_LOG_RAW_API_BODIES=file:<dir>).
• body_length : longueur du corps non tronqué. En octets UTF-8 lorsque OTEL_LOG_RAW_API_BODIES=file:<dir>, ou en unités de code UTF-16 lorsque =1
• body_truncated : "true" lorsqu'une troncature inline a eu lieu. Absent en mode fichier et lorsqu'aucune troncature n'a eu lieu.
• model : identifiant du modèle indiqué dans les paramètres de la requête
• query_source : sous-système ayant émis la requête (par exemple, "compact")
• request_body_id : UUID identifiant le corps de requête de cette tentative. L'événement api_response_body de la tentative qui réussit porte la même valeur, ce qui vous permet d'associer une réponse à la requête exacte qui l'a produite. Nécessite Claude Code v2.1.274 ou ultérieur

Événement de corps de réponse API

Journalisé pour chaque réponse API réussie lorsque OTEL_LOG_RAW_API_BODIES est défini.

En mode fichier (OTEL_LOG_RAW_API_BODIES=file:<dir>), Claude Code ajoute également une ligne JSON à <dir>/index.jsonl pour chaque réponse réussie, avec les champs timestamp, session_id, query_source, model, request_id, message_id, message_uuid, request_file et response_file. Lisez-le pour retrouver les fichiers de requête et de réponse associés à un message de transcription donné sans interroger votre backend de télémétrie. Le fichier d'index nécessite Claude Code v2.1.274 ou ultérieur.

Nom de l'événement : claude_code.api_response_body

Attributs :

• Tous les attributs standard
• event.name : "api_response_body"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• body : réponse de l'API Messages sérialisée en JSON, incluant l'id, les blocs de contenu, l'utilisation et la raison d'arrêt, tronquée à la limite de contenu (60 Ko par défaut). Le contenu de réflexion étendue est masqué. Émis uniquement en mode inline (OTEL_LOG_RAW_API_BODIES=1).
• body_ref : chemin absolu vers un fichier <dir>/<request_id>.response.json contenant le corps non tronqué. Émis uniquement en mode fichier (OTEL_LOG_RAW_API_BODIES=file:<dir>).
• body_length : longueur du corps non tronqué. En octets UTF-8 lorsque OTEL_LOG_RAW_API_BODIES=file:<dir>, ou en unités de code UTF-16 lorsque =1
• body_truncated : "true" lorsqu'une troncature inline a eu lieu. Absent en mode fichier et lorsqu'aucune troncature n'a eu lieu.
• model : identifiant du modèle
• query_source : sous-système ayant émis la requête
• request_id : ID de la requête API, par exemple "req_011...", décrit dans Attributs de corrélation des événements.
• request_body_id : le request_body_id de l'événement api_request_body auquel cette réponse répond. Nécessite Claude Code v2.1.274 ou ultérieur
• message.id : ID de message attribué par l'API à la réponse, c'est-à-dire le champ id du corps de la réponse. Nécessite Claude Code v2.1.274 ou ultérieur
• message.uuid : UUID de la dernière entrée de transcription de la réponse. Avec request_body_id, il relie un message de transcription aux corps de requête et de réponse correspondants. Nécessite Claude Code v2.1.274 ou ultérieur

Événement de décision d'outil

Journalisé lorsqu'une décision de permission d'outil est prise (acceptation/refus).

Nom de l'événement : claude_code.tool_decision

Attributs :

• Tous les attributs standard
• event.name : "tool_decision"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• tool_name : nom de l'outil (par exemple, "Read", "Edit", "Write", "NotebookEdit")
• tool_use_id : identifiant unique de cette invocation d'outil. Correspond au tool_use_id transmis aux hooks, ce qui permet de corréler les événements OTel avec les données capturées par les hooks.
• decision : "accept" ou "reject"
• tool_source : toujours présent. Provenance de l'outil, sous forme d'ensemble fermé de valeurs définies par la CLI. Nécessite Claude Code v2.1.214 ou ultérieur
  • "builtin" : les outils propres à la CLI
  • "mcp" : les serveurs MCP en général
  • "sdk_host_builtin_mcp" : un serveur in-process intégré à Claude Desktop lui-même, dans une session dont Claude Desktop est propriétaire. Claude Desktop est propriétaire d'une session qu'il a démarrée depuis l'un de ses propres points d'entrée, claude-desktop, claude-desktop-3p ou local-agent, lorsque cette session n'est pas un enfant imbriqué ; les sessions imbriquées, y compris celles que Claude Code lance lui-même, signalent ces serveurs comme "mcp"
• source : origine de la décision :
  • "config" : décision prise automatiquement sans demande de permission, en fonction des paramètres du projet, des règles d'autorisation ou de refus des paramètres personnels de l'utilisateur, de la politique gérée de l'entreprise, des flags --allowedTools ou --disallowedTools, du mode de permission actif, d'une autorisation limitée à la session accordée lors d'une demande de permission antérieure dans la même session CLI interactive, ou parce que l'outil est intrinsèquement sûr. L'événement n'indique pas laquelle de ces sources a correspondu. Claude Code signale également "config" lorsque la demande de permission elle-même échoue, par exemple lorsque le callback canUseTool de l'Agent SDK ou l'outil --permission-prompt-tool renvoie un résultat invalide, ou lorsque le flux d'entrée se ferme alors que la demande est en attente. Avant la v2.1.216, Claude Code signalait ces échecs comme "user_reject".
  • "hook" : un hook PreToolUse ou PermissionRequest a renvoyé la décision.
  • "user_permanent" : émis lorsque l'utilisateur a choisi « Yes, and don't ask again for ... » lors d'une demande de permission, ce qui enregistre une règle d'autorisation dans ses paramètres personnels. Dans la CLI interactive, cette valeur n'est émise que pour ce choix lui-même ; les appels ultérieurs qui correspondent à la règle enregistrée émettent "config" à la place. Dans les sessions Agent SDK ou -p non interactives, le choix initial comme les correspondances ultérieures avec la règle émettent "user_permanent". Traité comme une acceptation.
  • "user_temporary" : émis lorsque l'utilisateur a choisi « Yes » lors d'une demande de permission pour une approbation ponctuelle, ou a choisi une option accordant l'accès pour le reste de la session lors d'une demande de modification ou de lecture de fichier. Dans la CLI interactive, cette valeur n'est émise que pour le choix lui-même ; les appels ultérieurs autorisés par cette autorisation limitée à la session émettent "config" à la place. Dans les sessions Agent SDK ou -p non interactives, le choix comme les correspondances ultérieures émettent "user_temporary". Traité comme une acceptation.
  • "user_abort" : émis lorsque l'utilisateur a fermé la demande de permission sans répondre. Dans les sessions Agent SDK et -p non interactives, cela inclut l'interruption du tour alors qu'une demande de permission canUseTool ou --permission-prompt-tool est en attente ; avant la v2.1.216, Claude Code signalait cette interruption comme "user_reject". Traité comme un refus.
  • "user_reject" : émis lorsque l'utilisateur a choisi « No » lors de la demande. Dans la CLI interactive, cette valeur n'est émise que pour ce choix lui-même ; les appels qui correspondent à une règle de refus dans les paramètres personnels de l'utilisateur émettent "config" à la place. Dans les sessions Agent SDK ou -p non interactives, les appels qui correspondent à une règle de refus dans les paramètres personnels émettent "user_reject". Traité comme un refus.
• tool_parameters (lorsque OTEL_LOG_TOOL_DETAILS=1) : chaîne JSON contenant les paramètres propres à l'outil. Même structure que pour l'événement de résultat d'outil, sans les champs post-exécution comme git_commit_id. Les valeurs peuvent différer de celles de tool_result pour un appel accepté si la décision de permission réécrit l'entrée de l'outil via updatedInput. Utilisez cet attribut pour voir quelle commande a été refusée lorsque decision vaut "reject".
  • Pour les outils "sdk_host_builtin_mcp" : mcp_server_name et mcp_tool_name sont inclus même lorsque OTEL_LOG_TOOL_DETAILS est désactivé, car c'est l'application hôte qui définit ces noms ; sans eux, un appel refusé vers l'un de ces serveurs intégrés ne pourrait pas être attribué dans le flux par défaut. Pour les serveurs MCP configurés par l'utilisateur, le tool_name de l'événement est toujours la chaîne littérale "mcp_tool", et les noms du serveur et de l'outil n'apparaissent que dans tool_parameters lorsque le flag est activé ; le contenu des arguments nécessite le flag dans tous les cas. Nécessite Claude Code v2.1.214 ou ultérieur
  • Pour l'outil Bash : inclut bash_command, full_command, timeout, description, dangerouslyDisableSandbox. L'outil bash de l'espace de travail de l'application de bureau signale également tool_name comme Bash, mais inclut uniquement bash_command, full_command et timeout
  • Pour les outils MCP : inclut mcp_server_name, mcp_tool_name
  • Pour l'outil Skill : inclut skill_name
  • Pour l'outil Agent ou l'ancien outil Task : inclut subagent_type

Événement de changement de mode de permission

Journalisé lorsque le mode de permission change, par exemple lors d'un passage d'un mode à l'autre avec Shift+Tab, de la sortie du mode plan ou d'une vérification d'accès au mode auto.

Nom de l'événement : claude_code.permission_mode_changed

Attributs :

• Tous les attributs standard
• event.name : "permission_mode_changed"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• from_mode : mode de permission précédent, par exemple "default", "plan", "acceptEdits", "auto" ou "bypassPermissions"
• to_mode : nouveau mode de permission
• trigger : cause du changement. L'une des valeurs "shift_tab", "exit_plan_mode", "auto_gate_denied" ou "auto_opt_in". Absent lorsque la transition provient du SDK ou du bridge

Événement d'authentification

Journalisé lorsque /login ou /logout se termine.

Nom de l'événement : claude_code.auth

Attributs :

• Tous les attributs standard
• event.name : "auth"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• action : "login" ou "logout"
• success : "true" ou "false"
• auth_method : méthode d'authentification, par exemple "oauth"
• error_category : type d'erreur catégoriel lorsque l'action a échoué. Le message d'erreur brut n'est jamais inclus
• status_code : code de statut HTTP sous forme de chaîne lorsque l'action a échoué avec une erreur HTTP

Événement de connexion au serveur MCP

Journalisé lorsqu'un serveur MCP se connecte, se déconnecte ou ne parvient pas à se connecter.

Nom de l'événement : claude_code.mcp_server_connection

Attributs :

• Tous les attributs standard
• event.name : "mcp_server_connection"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• status : "connected", "failed" ou "disconnected"
• transport_type : transport du serveur, par exemple "stdio", "sse" ou "http"
• server_scope : portée à laquelle le serveur est configuré, par exemple "user", "project" ou "local"
• duration_ms : durée de la tentative de connexion en millisecondes
• error_code : code d'erreur lorsque la connexion a échoué
• is_plugin : true lorsque le serveur est fourni par un plugin, false sinon
• plugin_id_hash (lorsque is_plugin vaut true) : hachage stable du nom du plugin et de la marketplace, permettant de regrouper les événements par plugin sans exposer le nom. Claude Code le calcule comme décrit dans l'événement de chargement de plugin
• plugin.name (lorsque is_plugin vaut true) : nom du plugin qui fournit le serveur. Pour les plugins tiers, il s'agit de la chaîne littérale "third-party" sauf si OTEL_LOG_TOOL_DETAILS=1 ; cela évite par défaut que les noms de plugins tiers apparaissent dans les logs. Les plugins provenant de sources officielles d'Anthropic sont toujours identifiés par leur nom. Les attributs plugin_id_hash et plugin.name sont transmis à votre propre backend de monitoring et ne sont pas envoyés à Anthropic
• server_name (lorsque OTEL_LOG_TOOL_DETAILS=1) : nom configuré du serveur
• error (lorsque OTEL_LOG_TOOL_DETAILS=1) : message d'erreur complet lorsque la connexion a échoué

Événement d'erreur interne

Journalisé lorsque Claude Code intercepte une erreur interne inattendue. Seuls le nom de la classe d'erreur et un code de type errno sont enregistrés. Le message d'erreur et la stack trace ne sont jamais inclus. Cet événement n'est pas émis lors de l'exécution avec Amazon Bedrock, l'Agent Platform de Google Cloud ou Microsoft Foundry, ni lorsque DISABLE_ERROR_REPORTING est défini.

Nom de l'événement : claude_code.internal_error

Attributs :

• Tous les attributs standard
• event.name : "internal_error"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• error_name : nom de la classe d'erreur, par exemple "TypeError" ou "SyntaxError"
• error_code : code errno Node.js, par exemple "ENOENT", lorsqu'il est présent sur l'erreur

Événement d'installation de plugin

Journalisé lorsqu'un plugin termine son installation, aussi bien depuis la commande CLI claude plugin install que depuis l'interface interactive /plugin.

Nom de l'événement : claude_code.plugin_installed

Attributs :

• Tous les attributs standard
• event.name : "plugin_installed"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• marketplace.is_official : "true" si la marketplace est une marketplace officielle d'Anthropic, "false" sinon
• install.trigger : "cli" ou "ui"
• plugin.name : nom du plugin installé. Pour les marketplaces tierces, il n'est inclus que lorsque OTEL_LOG_TOOL_DETAILS=1
• plugin.version : version du plugin lorsqu'elle est déclarée dans l'entrée de la marketplace. Pour les marketplaces tierces, elle n'est incluse que lorsque OTEL_LOG_TOOL_DETAILS=1
• marketplace.name : marketplace depuis laquelle le plugin a été installé. Pour les marketplaces tierces, elle n'est incluse que lorsque OTEL_LOG_TOOL_DETAILS=1

Événement de chargement de plugin

Journalisé une fois par plugin activé au démarrage de la session. Utilisez cet événement pour inventorier les plugins actifs sur l'ensemble de votre parc, en complément de plugin_installed, qui enregistre l'action d'installation elle-même.

Nom de l'événement : claude_code.plugin_loaded

Attributs :

• Tous les attributs standard
• event.name : "plugin_loaded"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• plugin.name : nom du plugin. Pour les plugins extérieurs à la marketplace officielle et au bundle intégré, la valeur est "third-party" sauf si OTEL_LOG_TOOL_DETAILS=1
• marketplace.name : marketplace depuis laquelle le plugin a été installé, lorsqu'elle est connue. Masquée en "third-party" dans les mêmes conditions que plugin.name
• plugin.version : version indiquée dans le manifeste du plugin. Incluse uniquement lorsque le nom n'est pas masqué et que le manifeste déclare une version
• plugin.scope : catégorie de provenance du plugin : "official", "community", "org", "user-local" ou "default-bundle"
• enabled_via : manière dont le plugin a été activé : "default-enable", "org-policy", "admin-install", "seed-mount" ou "user-install". La valeur "admin-install" signifie que le plugin est défini comme obligatoire ou en installation automatique pour votre organisation dans Organization settings > Plugins & skills. Avant la v2.1.246, Claude Code signalait ces plugins comme "user-install" ou "seed-mount"
• plugin_id_hash : hachage déterministe du nom du plugin et de la marketplace, envoyé uniquement à votre exportateur configuré. Permet de compter les plugins tiers distincts chargés sur l'ensemble de votre parc sans enregistrer leurs noms. Pour les plugins synchronisés depuis claude.ai, Claude Code hache le nom du plugin avec le nom de marketplace que claude.ai indique pour ce plugin, ou avec synced à défaut. Avant la v2.1.246, Claude Code n'utilisait pas dans le hachage le nom de marketplace indiqué par claude.ai
• has_hooks : indique si le plugin fournit des hooks
• has_mcp : indique si le plugin fournit des serveurs MCP
• host_owned_mcp : true lorsque l'hôte du SDK gère les connexions MCP de ce plugin et que Claude Code n'a pas lu la configuration des serveurs MCP du plugin, false sinon. Nécessite Claude Code v2.1.172 ou ultérieur
• skill_path_count : nombre de répertoires de skills déclarés par le plugin
• command_path_count : nombre de répertoires de commandes déclarés par le plugin
• agent_path_count : nombre de répertoires d'agents déclarés par le plugin
• safe_mode : "true" lorsque la session a été démarrée avec --safe-mode, "false" sinon. En mode sans échec, cet événement ne rapporte que l'inventaire configuré ; les commandes, skills, hooks et serveurs MCP du plugin ne sont pas chargés. Nécessite Claude Code v2.1.169 ou ultérieur

Événement d'activation de skill

Journalisé lorsqu'un skill est invoqué, que Claude l'appelle via l'outil Skill ou que vous l'exécutiez sous forme de commande /.

Nom de l'événement : claude_code.skill_activated

Attributs :

• Tous les attributs standard
• event.name : "skill_activated"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• skill.name : nom du skill. Pour les skills définis par l'utilisateur et ceux de plugins tiers, la valeur est l'espace réservé "custom_skill" sauf si OTEL_LOG_TOOL_DETAILS=1
• invocation_trigger : mode de déclenchement du skill ("user-slash", "claude-proactive" ou "nested-skill")
• skill.source : emplacement depuis lequel le skill a été chargé (par exemple, "bundled", "userSettings", "projectSettings", "plugin")
• skill.kind : "workflow" lorsque le skill est un skill de workflow. Absent sinon
• plugin.name (lorsque OTEL_LOG_TOOL_DETAILS=1 ou que le plugin provient d'une marketplace officielle) : nom du plugin propriétaire lorsque le skill est fourni par un plugin
• marketplace.name (lorsque OTEL_LOG_TOOL_DETAILS=1 ou que le plugin provient d'une marketplace officielle) : marketplace depuis laquelle le plugin propriétaire a été installé, lorsque le skill est fourni par un plugin

Événement de mention @

Journalisé lorsque Claude Code résout une mention @ dans un prompt. Toutes les mentions n'émettent pas un événement : les chemins de sortie anticipée, comme les refus de permission, les fichiers trop volumineux, les pièces jointes de référence PDF et les échecs de listage de répertoires, se terminent sans journalisation.

Nom de l'événement : claude_code.at_mention

Attributs :

• Tous les attributs standard
• event.name : "at_mention"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• mention_type : type de mention ("file", "directory", "agent", "mcp_resource", "peer"). La valeur "peer" signifie que vous avez mentionné l'une de vos autres sessions Claude Code. Nécessite Claude Code v2.1.232 ou ultérieur
• success : indique si la mention a été résolue avec succès ("true" ou "false")

Événement d'épuisement des nouvelles tentatives API

Journalisé une seule fois lorsqu'une requête API échoue après plus d'une tentative. Émis en même temps que l'événement api_error final.

Nom de l'événement : claude_code.api_retries_exhausted

Attributs :

• Tous les attributs standard
• event.name : "api_retries_exhausted"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• model : modèle utilisé
• error : message d'erreur final
• status_code : code de statut HTTP sous forme de nombre. Absent pour les erreurs non HTTP.
• total_attempts : nombre total de tentatives effectuées
• total_retry_duration_ms : temps réel total écoulé sur l'ensemble des tentatives
• speed : "fast" ou "normal"

Événement d'enregistrement de hook

Journalisé une fois par hook configuré au démarrage de la session. Utilisez cet événement pour inventorier les hooks actifs sur l'ensemble de votre parc, en complément des événements par exécution hook_execution_start et hook_execution_complete.

Nom de l'événement : claude_code.hook_registered

Attributs :

• Tous les attributs standard
• event.name : "hook_registered"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• hook_event : type d'événement de hook, par exemple "PreToolUse" ou "PostToolUse"
• hook_type : type d'implémentation du hook : "command", "prompt", "mcp_tool", "http" ou "agent"
• hook_source : emplacement où le hook est défini : "userSettings", "projectSettings", "localSettings", "flagSettings", "policySettings" ou "pluginHook"
• safe_mode : "true" lorsque la session a été démarrée avec --safe-mode, "false" sinon. Nécessite Claude Code v2.1.169 ou ultérieur
• hook_matcher (lorsque OTEL_LOG_TOOL_DETAILS=1) : chaîne du matcher issue de la configuration du hook, lorsqu'elle est définie
• plugin.name (lorsque hook_source vaut "pluginHook") : nom du plugin contributeur. Pour les plugins extérieurs à la marketplace officielle et au bundle intégré, la valeur est "third-party" sauf si OTEL_LOG_TOOL_DETAILS=1
• plugin_id_hash (lorsque hook_source vaut "pluginHook") : hachage déterministe du nom du plugin et de la marketplace, envoyé uniquement à votre exportateur configuré. Permet de compter les plugins contributeurs distincts sans enregistrer leurs noms. Claude Code le calcule comme décrit dans l'événement de chargement de plugin

Événement de début d'exécution de hook

Journalisé lorsqu'un ou plusieurs hooks commencent à s'exécuter pour un événement de hook.

Nom de l'événement : claude_code.hook_execution_start

Attributs :

• Tous les attributs standard
• event.name : "hook_execution_start"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• hook_event : type d'événement de hook, par exemple "PreToolUse" ou "PostToolUse"
• hook_name : nom complet du hook incluant le matcher, par exemple "PreToolUse:Write"
• num_hooks : nombre de commandes de hook correspondantes
• managed_only : "true" lorsque seuls les hooks de la politique gérée sont autorisés
• hook_source : "policySettings" ou "merged"
• safe_mode : "true" lorsque la session a été démarrée avec --safe-mode, "false" sinon. Nécessite Claude Code v2.1.169 ou ultérieur
• hook_definitions : configuration du hook sérialisée en JSON. Incluse uniquement lorsque le traçage bêta détaillé et OTEL_LOG_TOOL_DETAILS=1 sont tous deux activés

Événement de fin d'exécution de hook

Journalisé lorsque tous les hooks d'un événement de hook ont terminé.

Nom de l'événement : claude_code.hook_execution_complete

Attributs :

• Tous les attributs standard
• event.name : "hook_execution_complete"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• hook_event : type d'événement de hook
• hook_name : nom complet du hook incluant le matcher
• num_hooks : nombre de commandes de hook correspondantes
• num_success : nombre de hooks terminés avec succès
• num_blocking : nombre de hooks ayant renvoyé une décision bloquante
• num_non_blocking_error : nombre de hooks ayant échoué sans bloquer
• num_cancelled : nombre de hooks annulés avant la fin
• total_duration_ms : durée réelle écoulée pour l'ensemble des hooks correspondants
• stdout_chars : nombre total de caractères de stdout pour les hooks correspondants ayant réussi. Nécessite Claude Code v2.1.280 ou ultérieur
• additional_context_chars : nombre total de caractères de additionalContext renvoyés par les hooks correspondants. Nécessite Claude Code v2.1.280 ou ultérieur
• system_message_chars : nombre total de caractères de systemMessage renvoyés par les hooks correspondants. Nécessite Claude Code v2.1.280 ou ultérieur
• initial_user_message_chars : nombre total de caractères de initialUserMessage renvoyés par les hooks correspondants. Nécessite Claude Code v2.1.280 ou ultérieur
• num_outputs_persisted : nombre de sorties de hook dépassant le plafond de 10 000 caractères que Claude Code a enregistrées dans un fichier. Nécessite Claude Code v2.1.280 ou ultérieur
• managed_only : "true" lorsque seuls les hooks de la politique gérée sont autorisés
• hook_source : "policySettings" ou "merged"
• safe_mode : "true" lorsque la session a été démarrée avec --safe-mode, "false" sinon. Nécessite Claude Code v2.1.169 ou ultérieur
• hook_definitions : configuration du hook sérialisée en JSON. Incluse uniquement lorsque le traçage bêta détaillé et OTEL_LOG_TOOL_DETAILS=1 sont tous deux activés

Événement de métriques de plugin de hook

Journalisé lorsqu'un hook de plugin de la marketplace officielle émet des métriques par invocation. Seuls les plugins installés depuis une marketplace officielle d'Anthropic peuvent les émettre. Les plugins de marketplaces tierces et les hooks configurés par l'utilisateur n'émettent pas cet événement. Utilisez cet événement pour surveiller le comportement des plugins, comme les taux de détection, les coûts et les durées, depuis votre propre stack d'observabilité.

Nom de l'événement : claude_code.hook_plugin_metrics

Attributs :

• Tous les attributs standard
• event.name : "hook_plugin_metrics"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• plugin_id : identifiant du plugin au format <name>@<marketplace>
• hook_event : type d'événement de hook ayant émis les métriques
• Jusqu'à 20 clés de métriques émises par le plugin. Les noms correspondent à ^[a-z][a-z0-9_]{0,39}$. Les valeurs sont booléennes ou numériques.

Événement de compaction

Journalisé lorsque la compaction de la conversation se termine.

Nom de l'événement : claude_code.compaction

Attributs :

• Tous les attributs standard
• event.name : "compaction"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit dans Attributs de corrélation des événements
• trigger : "auto" ou "manual"
• success : "true" ou "false"
• duration_ms : durée de la compaction
• pre_tokens : nombre approximatif de tokens avant la compaction
• post_tokens : nombre approximatif de tokens après la compaction
• error : message d'erreur lorsque la compaction a échoué
• precompute_reuse : défini uniquement lorsque trigger vaut "manual". La compaction automatique peut préparer un résumé en arrière-plan avant que la fenêtre de contexte ne soit pleine, et cet attribut indique si /compact a réutilisé ce résumé préparé. "hit" signifie qu'il a été réutilisé ; "miss_custom_instructions", "miss_hook" et "miss_not_ready" indiquent la raison pour laquelle un nouveau résumé a été calculé à la place. Nécessite Claude Code v2.1.153 ou ultérieur

Événement de sous-agent terminé

Enregistré lorsqu'un sous-agent se termine et renvoie son résultat à la conversation qui l'a lancé. Utilisez-le pour agréger l'utilisation des outils et la durée d'exécution par type de sous-agent ; pour agréger les tokens ou les coûts, utilisez le compteur de tokens et le compteur de coûts filtrés sur query_source "subagent", car le total_tokens de cet événement ne couvre que la requête finale. La catégorie "subagent" comptabilise également les requêtes provenant des hooks basés sur des agents, qui n'émettent aucun événement de sous-agent.

Nom de l'événement : claude_code.subagent_completed

Attributs :

• Tous les attributs standard
• event.name : "subagent_completed"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit sous Attributs de corrélation des événements
• agent_type : le type de sous-agent. Les noms des agents intégrés et des agents provenant de plugins de la marketplace officielle apparaissent tels quels ; les autres noms d'agents sont remplacés par "custom", sauf si OTEL_LOG_TOOL_DETAILS=1 est défini
• agent.source : l'origine de la définition de l'agent : built-in, plugin, ou la source de paramètres qui a défini un agent personnalisé, comme userSettings ou projectSettings
• is_built_in : indique si le sous-agent est un type d'agent intégré
• is_async : indique si le sous-agent s'est exécuté en arrière-plan
• total_tokens : l'empreinte en tokens de la requête API finale du sous-agent : les tokens d'entrée, de création de cache, de lecture du cache et de sortie de cette seule requête, soit approximativement la taille du contexte du sous-agent à la fin de son exécution. Il ne s'agit pas d'une somme sur l'ensemble de l'exécution
• total_tool_uses : nombre d'appels d'outils effectués par le sous-agent sur l'ensemble de l'exécution
• duration_ms : durée d'exécution en millisecondes
• model : le modèle sur lequel le sous-agent a été résolu pour s'exécuter
• final_model : le modèle qui a produit la réponse finale du sous-agent, qui diffère de model après un changement en cours d'exécution, par exemple vers un modèle de secours. Nécessite Claude Code v2.1.212 ou version ultérieure
• model_swapped : indique si plus d'un modèle a traité les requêtes du sous-agent. Nécessite Claude Code v2.1.212 ou version ultérieure
• plugin_id_hash, plugin.name : présents pour les agents fournis par des plugins. Les noms des plugins de la marketplace officielle apparaissent tels quels ; les autres noms de plugins sont remplacés par "third-party", sauf si OTEL_LOG_TOOL_DETAILS=1 est défini

Événement d'enquête de feedback

Enregistré lorsqu'une enquête sur la qualité de la session est affichée ou reçoit une réponse. Consultez Enquêtes sur la qualité des sessions pour savoir ce que collectent les enquêtes et comment les contrôler.

Nom de l'événement : claude_code.feedback_survey

Attributs :

• Tous les attributs standard
• event.name : "feedback_survey"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit sous Attributs de corrélation des événements
• event_type : événement du cycle de vie de l'enquête, par exemple "appeared", "responded" ou "transcript_prompt_appeared"
• appearance_id : identifiant unique reliant les événements émis pour une même instance d'enquête
• survey_type : l'enquête qui a produit l'événement. "session" correspond à la demande d'évaluation « How is Claude doing? »
• response : la sélection de l'utilisateur pour les événements responded
• enabled_via_override : true lorsque CLAUDE_CODE_ENABLE_FEEDBACK_SURVEY_FOR_OTEL est défini. Émis sous forme de booléen, et non de chaîne. Présent sur les événements d'enquête session. Filtrez sur cet attribut pour confirmer que le remplacement est appliqué sur l'ensemble d'un parc

Événement de balayage de rétention

Enregistré une fois par exécution du balayage de nettoyage de rétention, qui supprime les transcriptions de session et autres données d'application plus anciennes que la valeur du paramètre cleanupPeriodDays. Claude Code exécute le balayage en arrière-plan au plus une fois par session, et une exécution qui ne supprime rien émet tout de même l'événement. Si Claude Code a exécuté le balayage dans une session quelconque sur la même machine au cours des dernières 24 heures, il retarde le balayage de cette session d'au moins 10 minutes, de sorte qu'une session qui se termine plus tôt n'émet rien. Lorsque vous exécutez claude -p avec --bare, Claude Code n'exécute pas le balayage et n'émet rien.

Comme tous les événements OTel de cette page, il est envoyé uniquement au backend de télémétrie que vous configurez. Nécessite Claude Code v2.1.227 ou version ultérieure.

Lorsque Claude Code ne peut pas déterminer de manière sûre la période de rétention, il suspend le balayage et émet l'événement avec result défini sur "skipped" et un skip_reason. Lorsque des paramètres gérés définissent cleanupPeriodDays, la valeur gérée fixe la période de rétention et le balayage s'exécute même lorsqu'un fichier de paramètres d'une portée de priorité inférieure est endommagé ou invalide. Lorsque managed-settings.json lui-même ne peut pas être lu, Claude Code suspend quand même le balayage, sauf si le niveau géré fournit cleanupPeriodDays depuis une autre source, comme des paramètres gérés par le serveur ou un fichier déposé dans managed-settings.d/ à côté du fichier endommagé. Les attributs de compteur de suppressions ne sont présents que lorsque result vaut "complete".

Nom de l'événement : claude_code.retention_sweep

Attributs :

• Tous les attributs standard
• event.name : "retention_sweep"
• event.timestamp : horodatage ISO 8601
• event.sequence : compteur par processus pour ordonner les événements, décrit sous Attributs de corrélation des événements
• result : "complete" lorsque le balayage s'est exécuté, "skipped" lorsque Claude Code l'a suspendu
• period_days : la valeur de cleanupPeriodDays issue des paramètres fusionnés, en jours, ou 30 lorsqu'aucune source ne la définit. Sur les événements ignorés, il s'agit de la valeur que le balayage aurait utilisée, calculée à partir des sources de paramètres que Claude Code a pu lire
• used_default : "true" lorsqu'aucune source de paramètres lisible ne définit cleanupPeriodDays, "false" sinon. Sur les événements terminés, "true" signifie que la valeur par défaut de 30 jours s'est appliquée
• skip_reason : la raison pour laquelle Claude Code a suspendu le balayage. Présent uniquement lorsque result vaut "skipped" :
  • "user_source_disabled" : les paramètres utilisateur sont exclus, par exemple par le flag --setting-sources ou l'option settingSources du SDK, et aucune source activée ne fournit cleanupPeriodDays
  • "settings_unknowable" : un fichier de paramètres n'a pas pu être lu ou analysé, de sorte que cleanupPeriodDays ou desktopSessionCleanupPeriodDays pourrait être défini sur une valeur que Claude Code ne peut pas voir
  • "settings_invalid_key_set" : les paramètres comportent des erreurs de validation et cleanupPeriodDays ou desktopSessionCleanupPeriodDays est explicitement défini, de sorte que se rabattre sur la valeur par défaut pourrait supprimer ou conserver des fichiers contrairement à ce paramètre
• transcripts_deleted : nombre de transcriptions de session, c'est-à-dire les fichiers ~/.claude/projects/*/*.jsonl de premier niveau, que le balayage a supprimées
• transcripts_exempted_desktop : nombre de transcriptions ayant dépassé la période de rétention que le balayage a conservées en vertu de la règle Claude Desktop et Cowork. Elles ne sont pas comptabilisées dans files_past_cutoff. Nécessite Claude Code v2.1.248 ou version ultérieure
• session_files_deleted : nombre d'artefacts supprimés par le balayage des fichiers de session : les transcriptions ainsi que les fichiers associés à chaque session, tels que les fichiers annexes, les enregistrements et les résultats d'outils
• artifacts_deleted : nombre total d'éléments supprimés par le balayage dans les répertoires de données qu'il couvre, y compris les fichiers de session. Certains balayages comptent une arborescence de répertoires supprimée entière comme un seul élément et quelques passes de nettoyage ne contribuent pas au compteur ; considérez donc cette valeur comme un minimum plutôt que comme un nombre exact de fichiers
• files_retained_fresh : fichiers inspectés et laissés en place parce qu'ils sont toujours dans la période de rétention. Seuls les balayages fichier par fichier les comptabilisent, la valeur est donc un minimum ; une valeur non nulle correspond à l'état normal
• files_past_cutoff : fichiers plus anciens que la période de rétention que le balayage n'a pas réussi à supprimer, par exemple en raison d'une erreur de permission ou d'un fichier maintenu ouvert. Une valeur supérieure à zéro signifie que des fichiers ont survécu au-delà de la période de rétention configurée ; zéro ne prouve pas qu'aucun ne l'a fait, car l'échec de la suppression d'un répertoire entier est comptabilisé dans error_count à la place
• error_count : nombre d'erreurs rencontrées par le balayage lors du listage ou de la suppression de fichiers

Événement de résolution des paramètres gérés

Enregistré avec les paramètres gérés qu'une session a résolus : une fois au démarrage de la session, de nouveau lorsque les paramètres gérés ou l'état du programme d'aide de politique changent pendant la session, et lorsque Claude Code refuse de démarrer ou met fin à la session pour l'une des raisons répertoriées par l'attribut error.type. Utilisez cet événement pour repérer les machines qui s'exécutent sur une source gérée inattendue, les machines dont le programme d'aide de politique échoue, et la raison pour laquelle une machine a refusé de démarrer. Nécessite Claude Code v2.1.274 ou version ultérieure.

Par défaut, l'événement contient les sources gérées et l'état du programme d'aide de politique, mais pas les paramètres eux-mêmes. Pour ajouter l'attribut expurgé managed_settings.settings et l'empreinte managed_settings.resolved_sha256, définissez OTEL_LOG_MANAGED_SETTINGS=1 :

• Définissez-la dans le bloc env des paramètres gérés, des paramètres utilisateur ou de --settings, ou dans l'environnement avec lequel vous lancez Claude Code. Une valeur dans les paramètres de projet ou locaux ne l'active pas, car un dépôt cloné peut les écrire.
• Les paramètres gérés par le serveur peuvent la définir sans afficher la boîte de dialogue d'approbation de sécurité, car la variable ajoute uniquement la politique expurgée de votre organisation à un événement que votre organisation reçoit déjà.

Dans une session interactive au sein d'un dossier que vous n'avez pas approuvé, Claude Code n'exporte pas l'événement de refus.

Nom de l'événement : claude_code.managed_settings_resolved

Attributs :

• Tous les attributs standard

• event.name : "managed_settings_resolved"

• event.timestamp : horodatage ISO 8601

• event.sequence : compteur par processus pour ordonner les événements, décrit sous Attributs de corrélation des événements

• managed_settings.trigger : "startup" pour l'événement de démarrage de session, "change" lorsque les paramètres gérés ou l'état du programme d'aide de politique ont changé plus tard dans la session, ou "refused" lorsqu'une politique de paramètres gérés a arrêté la session. Claude Code envoie un événement change uniquement lorsqu'un attribut diffère du dernier événement envoyé, et une valeur de paramètre modifiée compte même lorsque OTEL_LOG_MANAGED_SETTINGS est désactivé

• error.type : la raison pour laquelle Claude Code a arrêté la session. Présent uniquement sur les événements refused :

  • "helper_failed" : une exécution du programme d'aide de politique a échoué
  • "policy_invalid" : les paramètres gérés contiennent une erreur qui empêche Claude Code de démarrer, ou une source d'administration n'a pas pu être chargée pour une raison autre qu'un refus de lecture, de sorte que Claude Code ne peut pas vérifier la connexion de l'organisation ni l'application des restrictions de fournisseur
  • "provider_not_allowed" : la session utiliserait un fournisseur d'API, ou enverrait le trafic d'un fournisseur vers un hôte, que la liste gérée allowedProviders n'autorise pas. Nécessite Claude Code v2.1.285 ou version ultérieure
  • "consent_rejected" : l'utilisateur a rejeté la boîte de dialogue d'approbation de sécurité pour les paramètres gérés par le serveur
  • "force_refresh_failed" : la récupération des paramètres exigée par forceRemoteSettingsRefresh a échoué
  • "gateway_rejected" : une passerelle d'applications Claude a répondu au chargement des paramètres gérés par un HTTP 403
  • "version_below_minimum" : cette version de Claude Code est inférieure à requiredMinimumVersion ou supérieure à requiredMaximumVersion
  • "_OTHER" : le chargement des paramètres gérés de la passerelle d'applications Claude a échoué pour une autre raison

• managed_settings.sources : chaque source gérée qui fournit au moins une clé de politique, par ordre de priorité décroissante, y compris les sources dont les clés ne prennent pas effet en mode first-wins. Les valeurs sont "remote", "plist" ou "hklm" pour la politique MDM ou au niveau du système d'exploitation, "file" pour les fichiers de paramètres gérés et les fichiers déposés, "parent" lorsqu'un hôte d'intégration fournit des paramètres, et "hkcu" pour la valeur de registre Windows HKCU lorsque Claude Code la lit. Une source qui ne contient que des clés de contrôle, ou que Claude Code n'a pas pu lire, n'est pas répertoriée. Émis sous forme de tableau de chaînes, vide lorsqu'aucune source gérée ne fournit de clé de politique

• managed_settings.source_behavior : la valeur de managedSourcesBehavior lue par Claude Code, "first-wins" ou "merge". "first-wins" lorsqu'aucune source ne définit la clé

• managed_settings.helper.state : état du programme d'aide de politique configuré par la source MDM ou fichier sélectionnée :

  • "ok" : la sortie du programme d'aide sert de paramètres gérés
  • "bad_path", "not_a_file", "exit_nonzero", "timed_out", "oversize", "parse_failed", "envelope_invalid" ou "schema_rejected" : la dernière exécution du programme d'aide a échoué. Échecs du programme d'aide décrit ces cas
  • "none" : aucun programme d'aide n'est configuré, ou la source qui le configure n'est ni une politique MDM ni un fichier de paramètres gérés

• managed_settings.helper.applied : "output" lorsque la sortie propre du programme d'aide sert de paramètres gérés, "none" dans le cas contraire

• managed_settings.helper.entry : "policyHelper" lorsque Claude Code a sélectionné un policyHelper. Absent lorsqu'aucun programme d'aide n'a été sélectionné

• managed_settings.helper.path : le path configuré du programme d'aide. Présent chaque fois que Claude Code a sélectionné un programme d'aide, que OTEL_LOG_MANAGED_SETTINGS soit défini ou non

• managed_settings.resolved_sha256 (lorsque OTEL_LOG_MANAGED_SETTINGS=1) : SHA-256 des paramètres gérés résolus avant expurgation, sérialisés en JSON avec les clés triées récursivement et sans espaces. Les machines ayant la même empreinte exécutent la même politique. Claude Code n'envoie l'empreinte qu'avec l'activation explicite, car une politique courte peut être retrouvée en hachant des suppositions. Absent lorsqu'aucun paramètre géré n'a été résolu, ainsi que sur les événements refused

• managed_settings.settings (lorsque OTEL_LOG_MANAGED_SETTINGS=1) : les noms et la structure des paramètres gérés résolus sous forme de chaîne JSON, avec les valeurs expurgées. Absent sur les événements refused. Claude Code le construit à partir de son schéma de paramètres :

  • Un nom de paramètre déclaré par le schéma est exporté, et une clé non déclarée est omise
  • Les booléens, les nombres et les valeurs de chaîne que le schéma restreint à un ensemble fixe d'options, comme permissions.defaultMode, sont exportés tels quels. sandbox.network.httpProxyPort et sandbox.network.socksProxyPort sont exportés sous la forme "[REDACTED]"
  • Toute autre chaîne, comme model, apiKeyHelper, chaque valeur env, chaque URL et chaque commande, est exportée sous la forme "[REDACTED]"
  • Les noms des entrées des maps, comme les noms de variables env et les identifiants de plugins, sont exportés tels quels. Un paramètre dont le schéma ne type pas les entrées, comme vimInsertModeRemaps, est exporté sous la forme d'un unique "[REDACTED]", et sandbox.ignoreViolations est exporté sous la forme d'une liste de ses listes de chemins, sans les motifs de commande
  • Une liste conserve sa longueur, chaque entrée étant expurgée selon les mêmes règles
  • Une règle permissions.allow, permissions.deny ou permissions.ask est exportée sous la forme de son nom d'outil avec le contenu expurgé, comme Read([REDACTED]), lorsque l'outil est intégré à cette version de Claude Code ou qu'il s'agit d'une référence mcp__ telle que mcp__jira__create_issue. Toute autre règle est exportée sous la forme "[REDACTED]"
  • Les hooks suivent les mêmes règles : les champs à options fixes et numériques comme type et timeout apparaissent, tandis que chaque commande, URL, matcher et condition if est exportée sous la forme "[REDACTED]"

  Par exemple, des paramètres gérés comportant apiKeyHelper, deux variables env et une règle de refus sont exportés sous la forme {"apiKeyHelper":"[REDACTED]","env":{"HTTPS_PROXY":"[REDACTED]","CLAUDE_CODE_ENABLE_TELEMETRY":"[REDACTED]"},"permissions":{"deny":["Read([REDACTED])"]}}.

  Claude Code tronque la valeur à 8 Ko d'UTF-8, et la valeur tronquée n'est pas du JSON valide

• managed_settings.settings_truncated (lorsque managed_settings.settings est présent) : true lorsque Claude Code a tronqué managed_settings.settings à 8 Ko, false sinon. Émis sous forme de booléen, et non de chaîne

Interpréter les données de métriques et d'événements

Les métriques et événements exportés prennent en charge une gamme d'analyses :

Surveillance de l'utilisation

Surveillance des coûts

La métrique claude_code.cost.usage aide à :

• Suivre les tendances d'utilisation entre les équipes ou les individus
• Identifier les sessions à utilisation élevée pour l'optimisation
• Attribuer les dépenses à des compétences, des plugins ou des types de sous-agents spécifiques via les attributs skill.name, plugin.name, et agent.name

Claude Code compte chaque réponse en streaming vers les métriques de coûts et de jetons exactement une fois, y compris lorsqu'une passerelle ou un proxy derrière ANTHROPIC_BASE_URL diffuse l'utilisation progressivement sur plusieurs images. Avant la v2.1.214, les flux qui contenaient l'utilisation dans plus d'une image gonflaient claude_code.cost.usage et claude_code.token.usage d'environ une demande complète supplémentaire par image supplémentaire.

Alertes et segmentation

Les alertes courantes à considérer :

• Pics de coûts
• Consommation de jetons inhabituelle
• Volume de session élevé d'utilisateurs spécifiques

Toutes les métriques peuvent être segmentées par les attributs standard. L'attribut model est disponible sur claude_code.token.usage, claude_code.cost.usage, et à partir de la v2.1.172, claude_code.lines_of_code.count.

Les ventilations par modèle des commits ne peuvent être approximées que en joignant les métriques de jetons ou de coûts sur session.id, puisqu'une session peut s'étendre sur plusieurs modèles. Filtrez le côté jetons ou coûts pour les lignes où query_source est "main" afin que les demandes auxiliaires et de sous-agents n'attribuent pas les commits de la session à un modèle qui ne les a pas effectués.

Détecter l'épuisement des tentatives

Claude Code réessaie les demandes d'API échouées en interne et n'émet un seul événement claude_code.api_error qu'après avoir abandonné, donc l'événement lui-même est le signal terminal pour cette demande. Les tentatives de nouvelle tentative intermédiaires ne sont pas enregistrées comme des événements séparés.

L'attribut attempt sur l'événement enregistre le nombre total de tentatives effectuées. CLAUDE_CODE_MAX_RETRIES est par défaut 10 et plafonné à 15. À partir de la v2.1.199, vous pouvez définir CLAUDE_CODE_RETRY_WATCHDOG pour augmenter la valeur par défaut et supprimer le plafond.

Lorsque la demande épuise toutes les tentatives sur une erreur transitoire, attempt est égal à un de plus que cette limite effective : 11 par défaut, et jamais plus de 16 sauf si le watchdog est défini. Une valeur inférieure indique une erreur non réessayable telle qu'une réponse 400, ou une cause avec son propre budget de tentatives plus petit. Par exemple, Claude Code réessaie un échec de chargement des identifiants AWS ou Google Cloud au maximum deux fois.

Pour distinguer une session qui s'est rétablie d'une qui s'est bloquée, groupez les événements par session.id et vérifiez si un événement api_request ultérieur existe après l'erreur.

Analyse des événements

Les données d'événements fournissent des informations détaillées sur les interactions de Claude Code :

Modèles d'utilisation des outils : analyser les événements de résultat d'outil pour identifier :

• Les outils les plus fréquemment utilisés
• Les taux de réussite des outils
• Les temps d'exécution moyens des outils
• Les modèles d'erreur par type d'outil

Surveillance des performances : suivre les durées des demandes d'API et les temps d'exécution des outils pour identifier les goulots d'étranglement de performance.

Mapper les tokens d'entrée aux conventions sémantiques GenAI d'OpenTelemetry

Claude Code exporte le nombre de tokens d'entrée tel qu'il apparaît dans le bloc usage de la réponse de l'API, de sorte que ces valeurs excluent les tokens lus depuis le cache de prompts ou écrits dans celui-ci :

• input_tokens sur le span claude_code.llm_request et l'événement api_request
• Le type "input" de la métrique claude_code.token.usage

Claude Code ne définit pas d'attributs gen_ai.usage.*. Les conventions sémantiques GenAI d'OpenTelemetry indiquent que gen_ai.usage.input_tokens doit inclure les tokens lus depuis le cache et écrits dans celui-ci. Pour calculer ce total :

• À partir du span ou de l'événement : additionnez input_tokens, cache_read_tokens et cache_creation_tokens
• À partir de la métrique claude_code.token.usage : additionnez ses types "input", "cacheRead" et "cacheCreation"

Les conventions définissent également des attributs distincts pour les lectures et les écritures dans le cache :

• cache_read_tokens correspond à gen_ai.usage.cache_read.input_tokens
• cache_creation_tokens correspond à gen_ai.usage.cache_write.input_tokens. Les versions antérieures des conventions nomment l'attribut d'écriture dans le cache gen_ai.usage.cache_creation.input_tokens, utilisez donc le nom attendu par votre backend.

Audit des événements de sécurité

Les événements OpenTelemetry sont la source de données d'audit pour l'activité de Claude Code. Chaque événement porte des attributs d'identité qui lient les appels d'outils, l'activité MCP et les décisions de permission à l'utilisateur qui les a déclenchés. L'exportateur de journaux OTLP peut livrer ces événements à n'importe quelle plateforme SIEM (Security Information and Event Management) avec un récepteur OTLP, ou à un collecteur OpenTelemetry qui transfère vers votre SIEM.

Attribuer les actions aux utilisateurs

Les attributs standard sur chaque événement incluent l'identité de l'utilisateur authentifié : user.email, user.account_uuid, user.account_id, et organization.id lorsqu'il est connecté avec un compte Claude ou, dans une session cloud, lorsque les propres identifiants de la session les portent, plus user.id et le per-session session.id. user.id est un identifiant limité à l'installation, sauf sur les sessions de passerelle d'applications Claude via /login, où il s'agit du sujet IdP du jeton émis par la passerelle.

Dans une session qu'un développeur démarre, les appels d'outils MCP, les commandes Bash et les éditions de fichiers sont donc attribués à ce développeur. Claude Code n'agit pas sous un compte de service distinct ; l'identité enregistrée sur chaque événement est le propre compte Claude du développeur, ou l'identité IdP du développeur sur une session de passerelle d'applications Claude. Dans les sessions de canal Claude Tag, Claude fonctionne plutôt comme l'identité partagée de votre organisation.

Lorsque Claude Code s'authentifie avec une clé API directe, ou contre Amazon Bedrock, Google Cloud's Agent Platform ou Microsoft Foundry, il n'y a pas de compte Claude dans la session et seuls user.id et session.id sont remplis. Dans ces déploiements, attachez l'identité utilisateur vous-même avec OTEL_RESOURCE_ATTRIBUTES, défini par utilisateur via le fichier paramètres gérés ou un wrapper de lancement. Les sessions de passerelle d'applications Claude n'ont besoin d'aucune de ces opérations : voir Attributs standard pour l'identité que leurs exportations portent.

export OTEL_RESOURCE_ATTRIBUTES="enduser.id=jdoe@example.com,enduser.directory_id=S-1-5-21-..."

Audit de l'activité MCP

Pour capturer l'activité du serveur MCP avec tous les détails d'appel, activez l'exportateur de journaux et définissez OTEL_LOG_TOOL_DETAILS=1. Chaque opération MCP produit alors des événements structurés qui portent le nom du serveur, le nom de l'outil et les arguments d'appel aux côtés des attributs d'identité standard :

Sans OTEL_LOG_TOOL_DETAILS, ces événements suppriment le détail d'identification :

• tool_result : conserve mcp_server_scope et un tool_name redacté au littéral "mcp_tool" pour les serveurs configurés par l'utilisateur, omet le contenu des arguments. Pour les serveurs intégrés de Claude Desktop, dans les sessions que Claude Desktop possède, il conserve également la paire mcp_server_name/mcp_tool_name à l'intérieur de tool_parameters, la même exception créée par l'hôte que tool_decision, nécessitant Claude Code v2.1.214 ou ultérieur
• tool_decision : conserve tool_source et un tool_name redacté au littéral "mcp_tool" pour les serveurs configurés par l'utilisateur, omet le contenu des arguments. Pour les serveurs intégrés de Claude Desktop, dans les sessions que Claude Desktop possède, il conserve également la paire mcp_server_name/mcp_tool_name à l'intérieur de tool_parameters ; tool_source et la paire de noms nécessitent tous deux Claude Code v2.1.214 ou ultérieur
• mcp_server_connection : omet server_name et le message d'erreur, mais conserve is_plugin, plugin_id_hash, et plugin.name, avec les noms de plugins non-Anthropic redactés au littéral "third-party", de sorte que les serveurs fournis par les plugins restent distinguables sans journalisation détaillée

Mapper les questions de sécurité aux événements

Lors de la création de règles de détection, recherchez le signal que vous souhaitez surveiller et interrogez votre backend pour l'événement correspondant et les attributs :

Claude Code émet uniquement le flux d'événements brut. La détection d'anomalies, l'établissement de lignes de base, la corrélation entre les sessions et les alertes sont la responsabilité de votre SIEM ou backend d'observabilité.

Envoyer les événements à un SIEM

Pointez OTEL_EXPORTER_OTLP_LOGS_ENDPOINT vers le récepteur OTLP de votre SIEM, ou vers un collecteur OpenTelemetry qui transfère vers l'API d'ingestion native de votre SIEM. L'exemple de paramètres gérés suivant exporte uniquement les événements, avec tous les détails d'outil activés pour l'audit MCP et Bash :

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_LOG_TOOL_DETAILS": "1",
    "OTEL_EXPORTER_OTLP_LOGS_PROTOCOL": "http/protobuf",
    "OTEL_EXPORTER_OTLP_LOGS_ENDPOINT": "https://siem.example.com:4318/v1/logs",
    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer your-siem-token"
  }
}

Pour confirmer que les événements arrivent, soumettez une invite dans une session exécutée sous cette configuration et vérifiez votre SIEM pour l'événement claude_code.user_prompt. Si rien n'arrive, démarrez Claude Code avec claude --debug-file <path> et vérifiez ce journal pour les erreurs d'exportation [3P telemetry].

Considérations relatives aux backends

Votre choix de backends de métriques, de journaux et de traces détermine les types d'analyses que vous pouvez effectuer :

Pour les métriques

• Bases de données de séries chronologiques : Calculs de taux, métriques agrégées
• Magasins colonnaires : Requêtes complexes, analyse d'utilisateurs uniques
• Plates-formes d'observabilité complètes : Requêtes avancées, visualisation, alertes

Pour les événements/journaux

• Systèmes d'agrégation de journaux : Recherche en texte intégral, analyse de journaux
• Magasins colonnaires : Analyse d'événements structurés
• Plates-formes d'observabilité complètes : Corrélation entre les métriques et les événements

Pour les traces

Choisissez un backend qui prend en charge le stockage de traces distribuées et la corrélation d'intervalles :

• Systèmes de traçage distribué : Visualisation d'intervalles, cascades de demandes, analyse de latence
• Plates-formes d'observabilité complètes : Recherche de traces et corrélation avec les métriques et les journaux

Pour les organisations nécessitant des métriques d'utilisateurs actifs quotidiens/hebdomadaires/mensuels (DAU/WAU/MAU), envisagez des backends qui prennent en charge les requêtes de valeurs uniques efficaces.

Informations sur le service

Toutes les métriques et tous les événements sont exportés avec les attributs de ressource suivants :

• service.name : claude-code pour les sessions de terminal, claude-code-desktop pour les sessions démarrées à partir de l'onglet Code dans l'application Claude Desktop
• service.version : Version actuelle de Claude Code, ou la version de l'application Desktop pour les sessions de l'onglet Code
• os.type : Type de système d'exploitation (par exemple, linux, darwin, windows)
• os.version : Chaîne de version du système d'exploitation
• host.arch : Architecture de l'hôte (par exemple, amd64, arm64)
• wsl.version : Numéro de version WSL (présent uniquement lors de l'exécution sur Windows Subsystem for Linux)
• Nom du compteur : com.anthropic.claude_code

Si vos pipelines de collecteur ou vos tableaux de bord filtrent sur service.name = claude-code, ajoutez claude-code-desktop au filtre pour capturer également la télémétrie des sessions de l'onglet Code.

Ressources de mesure du ROI

Pour un guide complet sur la mesure du retour sur investissement pour Claude Code, y compris la configuration de la télémétrie, l'analyse des coûts, les métriques de productivité et les rapports automatisés, consultez le Guide de mesure du ROI de Claude Code. Ce référentiel fournit des configurations Docker Compose prêtes à l'emploi, des configurations Prometheus et OpenTelemetry, et des modèles pour générer des rapports de productivité intégrés à des outils comme Linear.

Sécurité et confidentialité

• L'export OpenTelemetry vers votre backend est opt-in et nécessite une configuration explicite. Pour la télémétrie opérationnelle distincte d'Anthropic et comment la désactiver, consultez Utilisation des données
• Les contenus de fichiers bruts et les extraits de code ne sont pas inclus dans les métriques ou les événements. Les intervalles de trace constituent un chemin de données distinct : voir la puce OTEL_LOG_TOOL_CONTENT ci-dessous
• Lorsqu'authentifié via OAuth, user.email est inclus dans les attributs de télémétrie, envoyé uniquement au point de terminaison OTel que vous configurez, jamais à Anthropic. Si cela pose un problème pour votre organisation, travaillez avec votre backend de télémétrie pour filtrer ou masquer ce champ
• Le contenu des invites utilisateur n'est pas collecté par défaut. Seule la longueur de l'invite est enregistrée. Pour inclure le contenu de l'invite, définissez OTEL_LOG_USER_PROMPTS=1. Sous le traçage bêta détaillé, cette variable s'étend au-delà du texte d'invite : elle contrôle également l'attribut d'intervalle new_context, qui porte les résultats d'outil sur l'intervalle claude_code.llm_request
• Le texte de réponse de l'assistant n'est pas collecté par défaut. Seule la longueur de la réponse est enregistrée. Pour inclure le texte de réponse, définissez OTEL_LOG_ASSISTANT_RESPONSES=1. Comme toutes les données OpenTelemetry de Claude Code, le texte de réponse est envoyé uniquement au point de terminaison OTel que vous configurez, jamais à Anthropic. Lorsque cette variable n'est pas définie, OTEL_LOG_USER_PROMPTS est utilisé comme solution de secours, donc définissez OTEL_LOG_ASSISTANT_RESPONSES=0 si vous souhaitez le contenu de l'invite sans contenu de réponse
• Les arguments d'entrée d'outil et les paramètres ne sont pas enregistrés par défaut. Pour les inclure, définissez OTEL_LOG_TOOL_DETAILS=1. Pour les serveurs intégrés de Claude Desktop, dans les sessions que Claude Desktop possède, tool_decision et tool_result portent la paire mcp_server_name/mcp_tool_name, des noms créés par l'hôte plutôt que du contenu d'argument, même avec le drapeau désactivé. L'exception nécessite Claude Code v2.1.214 ou version ultérieure. Ces données sont envoyées uniquement au point de terminaison OTEL que vous configurez, jamais à Anthropic. Les arguments peuvent toujours contenir des valeurs sensibles, donc configurez votre backend de télémétrie pour filtrer ou masquer ces attributs selon les besoins. Lorsqu'activé :
  • Les événements tool_result et tool_decision incluent un attribut tool_parameters avec les commandes Bash, les noms de serveur MCP et d'outil, et les noms de compétences. Les champs tels que full_command sont émis sans troncature
  • Les événements tool_result incluent également un attribut tool_input avec les chemins de fichiers, les URL, les modèles de recherche et d'autres arguments. Les valeurs individuelles dépassant 512 caractères sont tronquées et le total est limité à environ 4 K caractères
  • Les événements user_prompt incluent le command_name verbatim pour les commandes personnalisées, de plugin et MCP
  • Les compteurs de coût et de jeton et les événements api_request, api_error et api_refusal portent les noms réels d'agent, de compétence, de plugin et de serveur MCP et d'outil dans leurs attributs d'attribution
  • Les intervalles de trace incluent le même attribut tool_input et les attributs dérivés de l'entrée tels que file_path, avec la même troncature que tool_input
• Le contenu d'outil n'est pas enregistré dans les intervalles de trace par défaut. Pour l'inclure, définissez OTEL_LOG_TOOL_CONTENT=1. L'intervalle claude_code.tool porte alors un événement d'intervalle tool.output avec les contenus de fichiers bruts, la sortie de commande Bash, et ce que les outils MCP, WebFetch et WebSearch retournent, tronqués à la limite de contenu (60 Ko par défaut) par attribut. Les résultats des outils MCP, WebFetch et WebSearch nécessitent Claude Code v2.1.283 ou version ultérieure. Le contenu d'outil atteint également les intervalles via new_context, dont la porte diffère par intervalle. Configurez votre backend de télémétrie pour filtrer ou masquer ces attributs selon les besoins
• Les corps bruts de la demande et de la réponse de l'API Messages d'Anthropic ne sont pas enregistrés par défaut. Pour les inclure, définissez OTEL_LOG_RAW_API_BODIES dans votre shell, vos paramètres utilisateur ou vos paramètres gérés. Il est ignoré dans les paramètres de projet et locaux. Les corps contiennent l'historique complet de la conversation, y compris l'invite système, chaque tour d'utilisateur et d'assistant antérieur, et les résultats d'outils, donc l'activation de cette option implique le consentement à tout ce que les autres drapeaux de contenu OTEL_LOG_* révèleraient. Claude Code masque toujours le contenu de réflexion étendue de Claude de ces corps, indépendamment des autres paramètres. La valeur que vous définissez détermine comment Claude Code livre les corps :

  • Avec =1, Claude Code émet des événements de journaux api_request_body et api_response_body pour chaque appel d'API. L'attribut body des événements porte la charge utile sérialisée en JSON, tronquée à la limite de contenu (60 Ko par défaut)

  • Avec =file:<dir>, Claude Code écrit les corps non tronqués dans les fichiers .request.json et .response.json sous ce répertoire, et les événements portent un chemin body_ref à la place du corps en ligne. Livrez le répertoire avec un collecteur de journaux ou un sidecar plutôt que via le flux de télémétrie.

    Pour chaque réponse réussie, Claude Code ajoute également une ligne à index.jsonl dans ce répertoire, reliant le fichier de réponse au fichier de demande qui l'a produit et au message de transcription qu'il est devenu. Chaque ligne ne contient aucun contenu de message, et la section événement du corps de réponse API énumère ses champs. Le fichier d'index nécessite Claude Code v2.1.274 ou version ultérieure

Surveiller Claude Code sur Amazon Bedrock

Pour des conseils détaillés sur la surveillance de l'utilisation de Claude Code pour Amazon Bedrock, consultez Implémentation de la surveillance de Claude Code (Amazon Bedrock).