20 20
21* **Conteneurs éphémères, par session** : exécutez chaque processus runner dans un conteneur ou une VM fraîche qui est détruite lorsque le processus se termine, avec `--capacity 1` et la valeur par défaut `--drain-grace-sec 0` afin que chaque conteneur serve exactement une session. À une capacité plus élevée, ou avec une période de drainage positive, un conteneur sert plusieurs sessions du même [propriétaire verrouillé](/docs/fr/self-hosted-environments#key-concepts) ; voir [Cycle de vie du runner](/docs/fr/self-hosted-environments#runner-lifecycle). Ne réutilisez pas un système de fichiers entre les redémarrages du runner, sauf dans la configuration délibérée [checkout pré-chauffé](#reuse-a-pre-warmed-checkout), et jamais entre les propriétaires.21* **Conteneurs éphémères, par session** : exécutez chaque processus runner dans un conteneur ou une VM fraîche qui est détruite lorsque le processus se termine, avec `--capacity 1` et la valeur par défaut `--drain-grace-sec 0` afin que chaque conteneur serve exactement une session. À une capacité plus élevée, ou avec une période de drainage positive, un conteneur sert plusieurs sessions du même [propriétaire verrouillé](/docs/fr/self-hosted-environments#key-concepts) ; voir [Cycle de vie du runner](/docs/fr/self-hosted-environments#runner-lifecycle). Ne réutilisez pas un système de fichiers entre les redémarrages du runner, sauf dans la configuration délibérée [checkout pré-chauffé](#reuse-a-pre-warmed-checkout), et jamais entre les propriétaires.
22 * <span id="processes-a-stopped-session-leaves" />Lorsque le runner arrête une session, il n'envoie aucun signal à un processus encore en cours d'exécution après la fin de sa commande shell, comme un service passé en mode daemon. La destruction du conteneur ou de la VM met fin à ce processus.22 * <span id="processes-a-stopped-session-leaves" />Lorsque le runner arrête une session, il n'envoie aucun signal à un processus encore en cours d'exécution après la fin de sa commande shell, comme un service passé en mode daemon. La destruction du conteneur ou de la VM met fin à ce processus.
23* **Pas de larges identifiants dans l'image** : n'incluez pas de clés SSH de longue durée, d'identifiants de fournisseur cloud, ou de jetons d'accès personnel qui accordent plus que ce qu'une session a besoin. Générez les identifiants utilisés pendant une session, tels que les jetons push ou API, par session à partir de votre [script wrapper](/docs/fr/self-hosted-environments-configuration#wrapper-scripts). Pour le clone initial, qui se produit avant l'exécution du wrapper, utilisez un [hook de cycle de vie `checkout`](/docs/fr/self-hosted-environments-configuration#checkout) ou [`--use-anthropic-git-proxy`](#use-the-anthropic-git-proxy) ; voir [Configurer git](#configure-git).23* **Pas de larges identifiants dans l'image** : n'incluez pas de clés SSH de longue durée, d'identifiants de fournisseur cloud, ou de jetons d'accès personnel qui accordent plus que ce qu'une session a besoin. Générez les identifiants utilisés pendant une session, tels que les jetons push ou API, par session à partir de votre [script wrapper](/docs/fr/self-hosted-environments-configuration#wrapper-scripts). Le clone initial se produit avant l'exécution du wrapper ; gérez-le donc avec un [hook de cycle de vie `checkout`](/docs/fr/self-hosted-environments-configuration#checkout), ou avec [`--use-anthropic-git-proxy`](#use-the-anthropic-git-proxy) lorsque tous les dépôts d'une session se trouvent sur github.com. Pour ces deux options, voir [Configurer git](#configure-git).
24* **Tenez les identifiants GitHub de l'hôte à l'écart des sessions** : Claude peut utiliser tout identifiant GitHub qu'une session peut lire, avec l'accès que cet identifiant accorde. Tenez les identifiants GitHub à portée étendue propres à l'hôte runner hors de tout ce qu'une session peut lire. Un tel identifiant peut être un jeton d'accès personnel, le jeton que `gh auth login` enregistre pour votre compte, ou un `GH_TOKEN` dans l'environnement du runner.
25 * **Avec [git géré par Anthropic](#use-the-anthropic-git-proxy)** : avec un tel identifiant, Claude atteint GitHub directement au lieu de passer par git géré par Anthropic.
26 * **Sans git géré par Anthropic** : un identifiant de clone peut rester dans l'image si vous limitez sa portée aussi strictement que le décrit [Intégrer la configuration git dans votre image](#ship-git-config-in-your-image).
24* **Gardez le secret de l'environnement loin des hôtes exécutant les sessions** : le secret de l'environnement peut enregistrer des runners et récupérer toute session mise en file d'attente sur l'environnement. Sur une flotte fixe, il réside sur chaque hôte runner, où le code de toute session peut lire le fichier secret. Préférez les [runners à la demande](/docs/fr/self-hosted-environments-configuration#on-demand-runners), où le secret reste sur l'hôte orchestrateur, qui n'exécute jamais de code utilisateur, et chaque runner reçoit un bon de travail à usage unique qui enregistre exactement un runner. Sur une flotte fixe, traitez le fichier secret-environnement comme lisible par toute session et faites tourner le secret après tout compromis de session suspecté.27* **Gardez le secret de l'environnement loin des hôtes exécutant les sessions** : le secret de l'environnement peut enregistrer des runners et récupérer toute session mise en file d'attente sur l'environnement. Sur une flotte fixe, il réside sur chaque hôte runner, où le code de toute session peut lire le fichier secret. Préférez les [runners à la demande](/docs/fr/self-hosted-environments-configuration#on-demand-runners), où le secret reste sur l'hôte orchestrateur, qui n'exécute jamais de code utilisateur, et chaque runner reçoit un bon de travail à usage unique qui enregistre exactement un runner. Sur une flotte fixe, traitez le fichier secret-environnement comme lisible par toute session et faites tourner le secret après tout compromis de session suspecté.
25* **Sortie réseau par défaut-refuser** : limitez le trafic sortant du conteneur runner et session à votre propre limite réseau sur chaque environnement ; [Sortie par défaut-refuser](#default-deny-egress) couvre ce qu'il faut autoriser et pourquoi.28* **Sortie réseau par défaut-refuser** : limitez le trafic sortant du conteneur runner et session à votre propre limite réseau sur chaque environnement ; [Sortie par défaut-refuser](#default-deny-egress) couvre ce qu'il faut autoriser et pourquoi.
26* **IAM hôte avec privilèges minimaux** : l'identité de calcul attachée à l'hôte runner, telle qu'un profil d'instance ou un compte de service de nœud, ne devrait accorder que ce dont le runner lui-même a besoin. Les sessions devraient obtenir leurs propres identifiants via votre script wrapper plutôt que d'hériter de ceux de l'hôte.29* **IAM hôte avec privilèges minimaux** : l'identité de calcul attachée à l'hôte runner, telle qu'un profil d'instance ou un compte de service de nœud, ne devrait accorder que ce dont le runner lui-même a besoin. Les sessions devraient obtenir leurs propres identifiants via votre script wrapper plutôt que d'hériter de ceux de l'hôte.
42 La garde s'exécute indépendamment de [`--trust-workspace`](/docs/fr/self-hosted-environments-reference#runner-cli-flags), et ne couvre pas les hooks de dépôt, `.mcp.json`, ou les règles Bash ; voir [Permissions et approbation des outils](/docs/fr/self-hosted-environments-configuration#permissions-and-tool-approval) pour savoir où ces autorisations doivent se trouver.45 La garde s'exécute indépendamment de [`--trust-workspace`](/docs/fr/self-hosted-environments-reference#runner-cli-flags), et ne couvre pas les hooks de dépôt, `.mcp.json`, ou les règles Bash ; voir [Permissions et approbation des outils](/docs/fr/self-hosted-environments-configuration#permissions-and-tool-approval) pour savoir où ces autorisations doivent se trouver.
43 46
44<Note>47<Note>
45 La liste d'autorisation IP de votre organisation ne couvre pas le trafic du runner auto-hébergé par défaut. Ne vous fiez pas à elle comme contrôle réseau pour le trafic du runner ou de la session ; appliquez plutôt une sortie par défaut-refuser à votre propre limite réseau, et contactez votre équipe de compte Anthropic si vous souhaitez l'application de la liste d'autorisation IP pour votre organisation.48 Si votre organisation a activé la [liste d'autorisation IP](https://support.claude.com/en/articles/13200993-restrict-access-to-claude-with-ip-allowlisting), ajoutez les adresses de sortie publiques de vos runners et conteneurs de session à la liste d'autorisation avant de les démarrer. Si vous exécutez des [runners à la demande](/docs/fr/self-hosted-environments-configuration#on-demand-runners), ajoutez également l'adresse de l'hôte orchestrateur. Ne vous fiez pas à la liste d'autorisation comme contrôle réseau pour le trafic du runner ou de la session. Appliquez plutôt une sortie par défaut-refuser à votre propre limite réseau.
46</Note>49</Note>
47 50
48<h2 id="network-requirements">51<h2 id="network-requirements">
55 58
56| Hôte | Port | Utilisé pour |59| Hôte | Port | Utilisé pour |
57| :- | :- | :- |60| :- | :- | :- |
58| `api.anthropic.com` | 443, HTTPS ; WSS pour le connecteur SCM uniquement | Plan de contrôle du runner et streaming de session, inférence de modèle, drapeaux de fonctionnalités, analytique de produit, récupérations de clés [JWKS](/docs/fr/self-hosted-environments-identity), signature de commit, le proxy git quand `--use-anthropic-git-proxy` est défini, et le tunnel [connecteur SCM](/docs/fr/self-hosted-environments-reference#scm-connector-flags) de l'orchestrateur quand `--scm-connector-host` est défini |61| `api.anthropic.com` | 443, HTTPS ; WSS pour le [git géré par Anthropic](#use-the-anthropic-git-proxy) | Plan de contrôle du runner et streaming de session, inférence de modèle, feature flags, analytique de produit, récupérations de clés [JWKS](/docs/fr/self-hosted-environments-identity), signature de commit, et git géré par Anthropic quand `--use-anthropic-git-proxy` est défini |
59| Votre hôte git, tel que `github.com` ou votre hôte GitHub Enterprise | 443 ou 22 | Clonage et push de référentiels. Non nécessaire si le runner utilise `--use-anthropic-git-proxy`, qui route le trafic git via `api.anthropic.com`. |62| Votre hôte git, tel que `github.com` ou votre hôte GitHub Enterprise | 443 ou 22 | Clonage et push de dépôts sur chaque hôte git utilisé par les sessions du runner. Sur un runner qui utilise [`--use-anthropic-git-proxy`](#use-the-anthropic-git-proxy), consultez [quand le chemin `github.com` reste nécessaire](#github-com-egress-with-the-anthropic-git-proxy). |
63
64<span id="github-com-egress-with-the-anthropic-git-proxy" />Un runner qui utilise [`--use-anthropic-git-proxy`](#use-the-anthropic-git-proxy) route son trafic git `github.com` via `api.anthropic.com`, il n'a donc pas besoin du chemin vers l'hôte git pour `github.com`. Il a toutefois besoin de ce chemin si vous définissez `--push-outcome-on-release` ou si vous effectuez un push depuis un hook `post-session`.
60 65
61Que ces hôtes soient nécessaires dépend de votre configuration :66Que ces hôtes soient nécessaires dépend de votre configuration :
62 67
71| `browser-intake-us5-datadoghq.com` | 443 | Téléchargements de rapports d'erreurs Anthropic, envoyés uniquement quand [le rapport d'erreurs](/docs/fr/data-usage#telemetry-services) est activé pour le compte de la session. Supprimé par `DISABLE_ERROR_REPORTING=1` ou `DISABLE_TELEMETRY=1`. |76| `browser-intake-us5-datadoghq.com` | 443 | Téléchargements de rapports d'erreurs Anthropic, envoyés uniquement quand [le rapport d'erreurs](/docs/fr/data-usage#telemetry-services) est activé pour le compte de la session. Supprimé par `DISABLE_ERROR_REPORTING=1` ou `DISABLE_TELEMETRY=1`. |
72| Les endpoints de votre fournisseur cloud pour les requêtes de modèle, les recherches de modèles et le renouvellement des identifiants, tels que `bedrock-runtime.us-east-1.amazonaws.com` ou `aiplatform.googleapis.com` | 443 | Uniquement quand le runner [envoie les requêtes de modèle à Amazon Bedrock ou à Agent Platform de Google Cloud](/docs/fr/self-hosted-environments-configuration#send-model-requests-to-bedrock-or-agent-platform) |77| Les endpoints de votre fournisseur cloud pour les requêtes de modèle, les recherches de modèles et le renouvellement des identifiants, tels que `bedrock-runtime.us-east-1.amazonaws.com` ou `aiplatform.googleapis.com` | 443 | Uniquement quand le runner [envoie les requêtes de modèle à Amazon Bedrock ou à Agent Platform de Google Cloud](/docs/fr/self-hosted-environments-configuration#send-model-requests-to-bedrock-or-agent-platform) |
73 78
74Le runner n'atteint pas `statsig.anthropic.com`, `*.sentry.io`, `claude.ai`, ou `platform.claude.com`. Ces hôtes apparaissent dans certaines listes de contrôle réseau d'entreprise plus anciennes, mais vous n'avez pas besoin de les autoriser pour le trafic du runner ou de la session : les récupérations de drapeaux de fonctionnalités vont à `api.anthropic.com`, et le runner s'authentifie avec le secret de l'environnement plutôt qu'avec OAuth interactif. Deux flux côté hôte atteignent `claude.ai`, donc exécutez-les à partir d'un hôte dont la sortie le permet plutôt que d'élargir la sortie du conteneur de session : l'installateur d'une ligne récupère `install.sh` depuis `claude.ai` au moment de l'installation, et `claude auth login` interactif, que le [guide de configuration](/docs/fr/self-hosted-environments-quickstart#set-up-an-environment-and-runner), le mode signé du `doctor`, et [la dispatch CI](/docs/fr/self-hosted-environments-testing#authenticate-from-ci) utilisent, se connecte via `claude.ai`, `claude.com`, et `platform.claude.com`. `mcp-proxy.anthropic.com` n'est pas requis non plus : les sessions auto-hébergées ne l'utilisent pas, et la livraison de vos connecteurs claude.ai d'organisation aux sessions, quand activée pour votre organisation, route via `api.anthropic.com`. Consultez [Serveurs MCP](/docs/fr/self-hosted-environments-configuration#mcp-servers).79Vous n'avez pas besoin d'ajouter ces hôtes à la liste d'autorisation pour le trafic du runner ou de la session :
80
81* **`statsig.anthropic.com`, `*.sentry.io`, `claude.ai` et `platform.claude.com`** : ces hôtes apparaissent dans certaines listes de contrôle réseau d'entreprise plus anciennes, mais le runner ne les atteint pas. Les récupérations de feature flags vont à `api.anthropic.com`, et le runner s'authentifie avec le secret de l'environnement plutôt qu'avec OAuth interactif.
82* **`mcp-proxy.anthropic.com`** : les sessions auto-hébergées ne l'utilisent pas. Quand la livraison des connecteurs est activée pour votre organisation, les connecteurs claude.ai de votre organisation atteignent les sessions via `api.anthropic.com`. Consultez [Serveurs MCP](/docs/fr/self-hosted-environments-configuration#mcp-servers).
83
84Ces flux côté hôte atteignent bien `claude.ai`, donc exécutez-les à partir d'un hôte dont la sortie le permet plutôt que d'élargir la sortie du conteneur de session :
85
86* **L'installateur d'une ligne** : récupère `install.sh` depuis `claude.ai` au moment de l'installation.
87* **`claude auth login` interactif** : se connecte via `claude.ai`, `claude.com` et `platform.claude.com`. La [configuration guidée](/docs/fr/self-hosted-environments-quickstart#run-the-guided-setup), le mode connecté de `doctor` et [le dispatch CI](/docs/fr/self-hosted-environments-testing#authenticate-from-ci) l'utilisent. Le navigateur avec lequel vous vous connectez charge également les vérifications de navigateur de la page de connexion claude.ai depuis `hcaptcha.com`, `*.hcaptcha.com` et `challenges.cloudflare.com`.
75 88
76<h3 id="default-deny-egress">89<h3 id="default-deny-egress">
77 Sortie par défaut-refuser90 Sortie par défaut-refuser
127* **Laisser le runner configurer git** : démarrez le runner avec `--configure-git` pour qu'il écrive la même identité et configuration de signature de commit que les sessions hébergées par Anthropic utilisent140* **Laisser le runner configurer git** : démarrez le runner avec `--configure-git` pour qu'il écrive la même identité et configuration de signature de commit que les sessions hébergées par Anthropic utilisent
128* **Livrer la configuration git dans votre image** : définissez l'identité et les identifiants push vous-même, par exemple pour committer sous votre propre identité de bot141* **Livrer la configuration git dans votre image** : définissez l'identité et les identifiants push vous-même, par exemple pour committer sous votre propre identité de bot
129 142
143Pour les dépôts sur github.com, vous pouvez également démarrer le runner avec [`--use-anthropic-git-proxy`](#use-the-anthropic-git-proxy), ou définir `CLAUDE_RUNNER_USE_GIT_PROXY=1`, pour demander à Anthropic de servir git pour les sessions du runner.
144
130Planchers de version Git sur l'hôte runner : [`--configure-git`](#let-the-runner-configure-git) la signature de commit SSH nécessite Git 2.34 ou plus récent, [`--use-anthropic-git-proxy`](#use-the-anthropic-git-proxy) nécessite 2.32 ou plus récent, et reprendre les sessions à partir de branches poussées par [`--push-outcome-on-release`](/docs/fr/self-hosted-environments-reference#runner-cli-flags) nécessite 2.29 ou plus récent. Git 2.24 est suffisant si vous omettez les trois et gérez l'identité git vous-même.145Planchers de version Git sur l'hôte runner : [`--configure-git`](#let-the-runner-configure-git) la signature de commit SSH nécessite Git 2.34 ou plus récent, [`--use-anthropic-git-proxy`](#use-the-anthropic-git-proxy) nécessite 2.32 ou plus récent, et reprendre les sessions à partir de branches poussées par [`--push-outcome-on-release`](/docs/fr/self-hosted-environments-reference#runner-cli-flags) nécessite 2.29 ou plus récent. Git 2.24 est suffisant si vous omettez les trois et gérez l'identité git vous-même.
131 146
132<h3 id="let-the-runner-configure-git">147<h3 id="let-the-runner-configure-git">
138* `user.name = Claude` et `user.email = noreply@anthropic.com`, correspondant aux sessions hébergées par Anthropic153* `user.name = Claude` et `user.email = noreply@anthropic.com`, correspondant aux sessions hébergées par Anthropic
139* Signature de commit et de tag au format SSH, routée via un shim géré par le runner qui signe chaque commit via le service de signature d'Anthropic en utilisant les identifiants de la session. Les signatures sont vérifiables sur GitHub par rapport à la clé de signature SSH publiée d'Anthropic.154* Signature de commit et de tag au format SSH, routée via un shim géré par le runner qui signe chaque commit via le service de signature d'Anthropic en utilisant les identifiants de la session. Les signatures sont vérifiables sur GitHub par rapport à la clé de signature SSH publiée d'Anthropic.
140* `push.negotiate = true`, donc git demande à votre hôte git quels commits il possède déjà avant de préparer un push. Nécessite Claude Code v2.1.257 ou plus récent.155* `push.negotiate = true`, donc git demande à votre hôte git quels commits il possède déjà avant de préparer un push. Nécessite Claude Code v2.1.257 ou plus récent.
141* `core.hooksPath` pointant vers un répertoire de hooks géré par le runner. Ses hooks `commit-msg` et `prepare-commit-msg` ajoutent une remorque `Co-authored-by:` pour le créateur de la session à chaque commit, construite à partir de l'email dans [`CCR_SESSION_ACCOUNT_EMAIL`](/docs/fr/self-hosted-environments-configuration#wrapper-scripts) et omise quand cette variable n'est pas définie. Si votre image définit déjà `core.hooksPath`, le runner laisse votre paramètre en place, ignore l'installation de ces hooks, et affiche un avertissement `[runner:git]`.156* `core.hooksPath` pointant vers un répertoire de hooks géré par le runner. Ses hooks `commit-msg` et `prepare-commit-msg` ajoutent une remorque `Co-authored-by:` pour le créateur de la session à chaque commit. La remorque est construite à partir de l'email dans [`CCR_SESSION_ACCOUNT_EMAIL`](/docs/fr/self-hosted-environments-configuration#wrapper-scripts) et omise quand cette variable n'est pas définie. Si votre image définit déjà `core.hooksPath` et que le runner n'utilise pas [git géré par Anthropic](#use-the-anthropic-git-proxy), le runner laisse votre paramètre en place, ignore l'installation de ces hooks, et affiche un avertissement `[runner:git]`.
142 157
143La signature de commit nécessite git 2.34 ou plus récent ; le runner vérifie au démarrage et quitte avec une erreur si votre git est plus ancien. Ce drapeau ne configure pas les identifiants push, que vous fournissez toujours dans l'image.158La signature de commit nécessite git 2.34 ou plus récent ; le runner vérifie au démarrage et quitte avec une erreur si votre git est plus ancien. Ce drapeau ne configure pas les identifiants push, que vous fournissez toujours dans l'image.
144 159
145Sur un runner en v2.1.280 ou plus récent, les commits que vous créez depuis un hook de cycle de vie `checkout` ou `post-session` sont également signés au nom de la session, sans la remorque `Co-authored-by:`. [Configuration git dans les hooks de cycle de vie](/docs/fr/self-hosted-environments-configuration#git-configuration-inside-lifecycle-hooks) décrit les paramètres git que le runner impose dans ces hooks.160Sur un runner en v2.1.280 ou plus récent, les commits que vous créez depuis un hook de cycle de vie `checkout` ou `post-session` sont également signés au nom de la session, sans la remorque `Co-authored-by:`. [Configuration git dans les hooks de cycle de vie](/docs/fr/self-hosted-environments-configuration#git-configuration-inside-lifecycle-hooks) décrit les paramètres git que le runner impose dans ces hooks.
146 161
162Avec ou sans `--configure-git`, Claude Code demande à Claude de terminer ses messages de commit par une remorque `Claude-Session: <url>` et ses descriptions de pull request par l'URL de la session. Pour omettre les deux, définissez [`attribution.sessionUrl`](/docs/fr/settings-reference#attribution-sessionurl) sur `false` dans le fichier [`~/.claude/settings.json`](/docs/fr/self-hosted-environments-configuration#how-each-session’s-config-is-assembled) de l'hôte runner, puis redémarrez le runner.
163
147<h3 id="ship-git-config-in-your-image">164<h3 id="ship-git-config-in-your-image">
148 Livrer la configuration git dans votre image165 Livrer la configuration git dans votre image
149</h3>166</h3>
186 Utiliser le proxy git Anthropic203 Utiliser le proxy git Anthropic
187</h3>204</h3>
188 205
189Démarrez le runner avec `--use-anthropic-git-proxy`, ou définissez `CLAUDE_RUNNER_USE_GIT_PROXY=1`, pour qu'il clone via le proxy git d'Anthropic, authentifié avec le jeton court-durée de la session. Pour les sessions utilisateur ordinaires, le proxy utilise le jeton OAuth GitHub ou GitHub Enterprise stocké pour le créateur de session ; pour les sessions de bot et d'agent, il utilise le jeton d'installation GitHub App de votre organisation. De toute façon, l'image runner n'a besoin d'aucun identifiant git : pas de clés SSH, pas de credential helper, pas de `.netrc`. C'est le même chemin d'authentification que les environnements hébergés par Anthropic utilisent.206Avec le proxy git Anthropic, également appelé git géré par Anthropic, l'image du runner n'a besoin d'aucune clé SSH, d'aucun credential helper, d'aucun `.netrc` ni d'aucun autre identifiant git pour la session elle-même. À la place, le runner demande à Anthropic de servir git pour ses sessions. Pour la session d'un utilisateur qu'Anthropic sert, le clone du runner ainsi que les récupérations et les pushs propres à la session passent par Anthropic, qui utilise le jeton OAuth GitHub stocké pour le créateur de la session. [Comment Anthropic sert git pour une session](#how-anthropic-serves-git-for-a-session) couvre les sessions de bot et d'agent.
207
208Le proxy git est désactivé tant que vous ne l'[activez](#turn-the-anthropic-git-proxy-on) pas. Un runner qui atteint votre hôte git avec ses propres identifiants n'en a pas besoin, et son git fonctionne avec n'importe quel hôte git.
209
210En contrepartie, le proxy git limite ce que le runner prend en charge et modifie ce dont il a besoin :
211
212* **github.com uniquement** : Anthropic ne sert une session que lorsque tous ses dépôts sont sur github.com, et le proxy git ne prend pas encore en charge GitHub Enterprise Server. Sur un runner avec le proxy git, une session ayant un dépôt sur un autre hôte git [ne démarre pas](#when-anthropic-doesnt-serve-a-session).
213* **Comptes GitHub connectés** : la personne qui a créé une session utilisateur doit avoir connecté GitHub sur claude.ai, sinon la session [ne démarre pas](#creator-has-no-github-connection).
214* **`--capacity 1`** : le proxy git nécessite une session par processus runner, donc exécutez plus de répliques pour le parallélisme. [Activer le proxy git Anthropic](#turn-the-anthropic-git-proxy-on) liste les exigences.
215* **Configuration git globale remplacée** : le runner [supprime et remplace la configuration git globale](#git-proxy-replaces-global-git-config) de l'utilisateur sous lequel il s'exécute. Exécutez-le en tant qu'utilisateur dédié ou dans un conteneur.
216* **Identifiants de l'hôte pour les pushs de l'hôte** : le push [`--push-outcome-on-release`](/docs/fr/self-hosted-environments-reference#runner-cli-flags) du runner et tout push effectué par votre [hook `post-session`](/docs/fr/self-hosted-environments-configuration#post-session) utilisent toujours les propres identifiants git de l'hôte runner et son [chemin réseau vers `github.com`](#github-com-egress-with-the-anthropic-git-proxy). Pour ces identifiants, consultez [Livrer la configuration git dans votre image](#ship-git-config-in-your-image).
217* **Décision par session** : Anthropic décide pour chaque session du runner s'il sert son git, et une session qu'il ne sert pas ne démarre pas. [Quand des sessions ne démarrent pas sur un runner avec le proxy git](#when-anthropic-doesnt-serve-a-session) couvre les causes.
218
219<span id="git-proxy-replaces-global-git-config" />
220
221<Warning>
222 Lorsque `--use-anthropic-git-proxy` est défini, le runner supprime et remplace la configuration git globale de l'utilisateur sous lequel il s'exécute, sans conserver de sauvegarde. Il le fait au démarrage et avant chaque session. Un identifiant de connexion ou un credential helper que vous y conserviez est perdu. Les paramètres écrits par [`--configure-git`](#let-the-runner-configure-git) sont conservés. Exécutez le runner en tant qu'utilisateur dédié ou dans un conteneur, jamais sous votre propre utilisateur.
223</Warning>
224
225Conservez les paramètres git qui ne sont pas secrets, comme l'identité et `safe.directory`, dans la configuration git système.
226
227<h4 id="turn-the-anthropic-git-proxy-on">
228 Activer le proxy git Anthropic
229</h4>
230
231Avant de démarrer le runner avec `--use-anthropic-git-proxy`, vérifiez que l'hôte runner satisfait chacune de ces exigences. Le runner refuse de démarrer lorsque l'exigence de capacité ou de git n'est pas satisfaite :
190 232
191Le proxy nécessite `--capacity 1` car l'URL du proxy est par session, et git 2.32 ou plus récent car les anciennes versions de git ignorent le mécanisme de configuration que le proxy utilise pour isoler les sessions les unes des autres. Le runner refuse de démarrer si l'une ou l'autre exigence n'est pas satisfaite. Parce que le proxy récupère du côté d'Anthropic, votre hôte git doit être accessible depuis l'infrastructure Anthropic, la même exigence que les sessions hébergées par Anthropic ont ; pour un hôte git qui n'est routable que dans votre réseau, utilisez un [hook de cycle de vie `checkout`](/docs/fr/self-hosted-environments-configuration#checkout) à la place. Chaque processus runner gère une session à la fois, donc exécutez plus de répliques pour le parallélisme. Quand le proxy est activé, `--git-host-rewrite` et `--git-ssh-rewrite` n'ont aucun effet : l'URL du proxy pointe vers `api.anthropic.com`, pas votre hôte git.233* **Claude Code v2.1.267 ou plus récent** : les versions antérieures acceptent le flag mais ne transmettent pas la demande pour qu'Anthropic serve git et n'affichent pas la ligne `Registering as opted in`, donc Anthropic ne sert pas leurs sessions.
234* **`--capacity 1`, la valeur par défaut** : chaque processus runner gère une session à la fois, donc exécutez plus de répliques pour le parallélisme.
235* **Git 2.32 ou plus récent** : les anciennes versions de git ignorent la configuration git par session que le runner met en place pour le proxy git.
192 236
193<Warning>237<Warning>
194 Les recettes [Kubernetes](#kubernetes) et [Docker Compose](#docker-compose) sur cette page utilisent `--capacity 4`. Si vous ajoutez `--use-anthropic-git-proxy` ou `CLAUDE_RUNNER_USE_GIT_PROXY=1` à l'une d'elles sans changer la capacité à `1`, le runner quitte au démarrage chaque fois que votre orchestrateur le redémarre. Définissez `--capacity 1` et exécutez plus de répliques pour le parallélisme. [When the runner exits](#when-the-runner-exits) affiche la ligne que le runner imprime.238 Les recettes [Kubernetes](#kubernetes) et [Docker Compose](#docker-compose) sur cette page utilisent `--capacity 4`. Si vous ajoutez `--use-anthropic-git-proxy` ou `CLAUDE_RUNNER_USE_GIT_PROXY=1` à l'une d'elles sans changer la capacité à `1`, le runner quitte au démarrage chaque fois que votre orchestrateur le redémarre. Définissez `--capacity 1` et exécutez plus de répliques pour le parallélisme. [When the runner exits](#when-the-runner-exits) affiche la ligne que le runner imprime.
195</Warning>239</Warning>
196 240
197Le runner signale également l'adhésion à Anthropic quand il s'enregistre, affichant `Registering as opted in to Anthropic-managed git (--use-anthropic-git-proxy)` au démarrage. Signaler l'adhésion nécessite Claude Code v2.1.267 ou plus récent, et les versions antérieures acceptent le drapeau sans le signaler ou afficher cette ligne. Chaque session sur un runner ayant adhéré utilise ensuite soit git géré par Anthropic, soit l'URL du proxy par session. Quand une session utilise l'URL du proxy par session, le runner enregistre une ligne `[runner:warn]` indiquant cela.241Pour activer le proxy git, ajoutez `--use-anthropic-git-proxy` à la commande du runner, ou définissez `CLAUDE_RUNNER_USE_GIT_PROXY=1` dans l'environnement du runner. Cette commande, exécutée dans un shell sur l'hôte runner, démarre le runner du [démarrage rapide](/docs/fr/self-hosted-environments-quickstart#set-up-manually) avec le proxy git activé :
242
243```bash theme={null}
244claude self-hosted-runner --environment-secret-file '/etc/claude/environment-secret' --base-dir '<writable-dir>' --use-anthropic-git-proxy
245```
246
247Au démarrage, le runner affiche `Registering as opted in to Anthropic-managed git (--use-anthropic-git-proxy)`. Anthropic décide ensuite pour chaque session de ce runner s'il sert son git. Pour chaque session qu'il sert, le runner journalise une ligne `[runner:session]` contenant `governed git ACTIVE`. Si une session ne démarre pas, consultez [Quand des sessions ne démarrent pas sur un runner avec le proxy git](#when-anthropic-doesnt-serve-a-session).
248
249<h4 id="how-anthropic-serves-git-for-a-session">
250 Comment Anthropic sert git pour une session
251</h4>
252
253Pour une session qu'Anthropic sert, le clone du runner ainsi que les récupérations et les pushs propres à la session passent par Anthropic, authentifiés avec le jeton de courte durée propre à la session :
254
255* **Sessions utilisateur** : Anthropic utilise le jeton OAuth GitHub stocké pour le créateur de la session.
256* **Sessions de bot et d'agent** : Anthropic utilise le jeton d'installation GitHub App de votre organisation.
257* **Réécritures d'URL** : `--git-host-rewrite` et `--git-ssh-rewrite` n'ont aucun effet sur un dépôt que le proxy git sert.
258
259<h4 id="when-anthropic-doesnt-serve-a-session">
260 Quand des sessions ne démarrent pas sur un runner avec le proxy git
261</h4>
262
263Sur un runner démarré avec `--use-anthropic-git-proxy`, une session ne démarre pas lorsqu'Anthropic ne sert pas son git. Recherchez dans le log du runner une erreur git qui nomme une adresse `api.anthropic.com` contenant `/git_proxy/`.
264
265Pour chaque session, un runner sur Claude Code v2.1.267 ou plus récent journalise également soit une ligne `[runner:session]` contenant `governed git ACTIVE` lorsqu'Anthropic sert le git de la session, soit une ligne `[runner:warn]` contenant `the server withheld Anthropic-managed git for this session` lorsqu'il ne le sert pas. Trouvez la ligne que vous voyez parmi ces cas :
266
267* **Ni `governed git ACTIVE` ni la ligne `withheld`** : un runner antérieur à Claude Code v2.1.267 ne journalise aucune des deux lignes, et Anthropic ne sert pas ses sessions. Mettez à jour le runner vers v2.1.267 ou plus récent en suivant [Épingler la version](#pin-the-version).
268* **La ligne `withheld`** : Anthropic n'a pas servi la session. Un runner qui fonctionnait auparavant avec le proxy git peut échouer ainsi sans aucun changement de votre côté.
269 * **Un dépôt n'est pas sur github.com** : une session ayant ne serait-ce qu'un dépôt sur un autre hôte git, comme GitHub Enterprise Server, n'est pas servie, y compris ses dépôts github.com. [Désactivez le proxy git Anthropic](#turn-the-anthropic-git-proxy-off) pour les runners de cet environnement.
270 * **Tous les dépôts sont sur github.com** : signalez l'échec à [votre équipe de compte Anthropic](#report-an-issue) avec l'identifiant de session figurant dans la ligne `withheld`. Anthropic enregistre la raison de son côté.
271* **Une ligne contenant `remote: access denied by the git proxy`** : une session qu'Anthropic sert peut tout de même être refusée, par exemple lorsque la politique de l'organisation refuse l'accès git pour la session, ou que la session n'est pas autorisée pour le dépôt. Le log du runner affiche alors une ligne contenant `remote: access denied by the git proxy`, et le reste de cette ligne en indique la raison.
272* <span id="creator-has-no-github-connection" />**`GitHub authentication required`** : ce message apparaît lorsque le créateur de la session n'a pas de connexion GitHub fonctionnelle sur claude.ai. Le clone de la session échoue, et l'erreur git indique `GitHub authentication required. Please reconnect your GitHub account.` Demandez à cette personne de connecter ou reconnecter GitHub dans ses paramètres claude.ai.
273
274Après avoir corrigé la cause, redémarrez les sessions qui ont échoué.
275
276<h4 id="turn-the-anthropic-git-proxy-off">
277 Désactiver le proxy git Anthropic
278</h4>
279
280Si des sessions d'un environnement utilisent un dépôt sur un hôte git autre que github.com, comme GitHub Enterprise Server, désactivez `--use-anthropic-git-proxy` pour les runners de cet environnement.
281
282<Steps>
283 <Step title="Retirer le flag">
284 Retirez `--use-anthropic-git-proxy` de la commande du runner. Si vous avez défini `CLAUDE_RUNNER_USE_GIT_PROXY` dans l'environnement du runner, comme une spécification de pod ou un fichier Compose, retirez-la à cet endroit. Dans un shell, supprimez sa définition :
285
286 ```bash theme={null}
287 unset CLAUDE_RUNNER_USE_GIT_PROXY
288 ```
289 </Step>
290
291 <Step title="Fournir des identifiants git au runner">
292 Fournissez des identifiants qui fonctionnent sans invite pour chaque hôte git utilisé par les sessions des runners, github.com compris. Tout identifiant qui se trouvait dans la configuration git globale de l'utilisateur du runner a disparu, car le runner a supprimé cette configuration tant que `--use-anthropic-git-proxy` était défini. [Livrez les identifiants dans votre image](#ship-git-config-in-your-image) ou utilisez un [hook de cycle de vie `checkout`](/docs/fr/self-hosted-environments-configuration#checkout).
293 </Step>
294
295 <Step title="Ouvrir le chemin réseau">
296 Autorisez le runner à atteindre chaque hôte git utilisé par les sessions des runners sur le port 443 ou 22. Consultez la ligne relative à l'hôte git dans [Exigences réseau](#network-requirements).
297 </Step>
298
299 <Step title="Redémarrer les runners">
300 Redémarrez les runners pour qu'ils s'enregistrent sans le proxy git. Puis redémarrez chaque session qui a échoué.
301 </Step>
302</Steps>
198 303
199<h4 id="github-api-access-without-the-github-cli">304<h4 id="github-api-access-without-the-github-cli">
200 Accès à l'API GitHub sans la GitHub CLI305 Accès à l'API GitHub sans la GitHub CLI
266```dockerfile theme={null}371```dockerfile theme={null}
267FROM debian:bookworm-slim372FROM debian:bookworm-slim
268ARG CLAUDE_CODE_VERSION373ARG CLAUDE_CODE_VERSION
269RUN apt-get update && apt-get install -y --no-install-recommends git curl ca-certificates openssh-client \374RUN apt-get update && apt-get install -y --no-install-recommends git curl ca-certificates openssh-client jq \
270 && rm -rf /var/lib/apt/lists/*375 && rm -rf /var/lib/apt/lists/*
271RUN curl -fsSL "https://downloads.claude.ai/claude-code-releases/${CLAUDE_CODE_VERSION:?set with --build-arg CLAUDE_CODE_VERSION}/linux-x64/claude" \376RUN curl -fsSL "https://downloads.claude.ai/claude-code-releases/${CLAUDE_CODE_VERSION:?set with --build-arg CLAUDE_CODE_VERSION}/linux-x64/claude" \
272 -o /usr/local/bin/claude && chmod +x /usr/local/bin/claude377 -o /usr/local/bin/claude && chmod +x /usr/local/bin/claude
382kubectl create namespace claude-runners487kubectl create namespace claude-runners
383```488```
384 489
385Créez le Secret de sauvegarde à partir d'un fichier local contenant la valeur que vous avez copiée à l'étape [**Copier la clé d'environnement**](/docs/fr/self-hosted-environments-quickstart#set-up-an-environment-and-runner) de l'interface utilisateur d'administration, pour que le secret n'apparaisse jamais dans votre historique de shell. Exécutez `(umask 077 && cat > ./environment-secret)`, collez le secret, appuyez sur Entrée, puis Ctrl-D. Ensuite, créez le Secret et supprimez le fichier :490Créez le Secret de sauvegarde à partir d'un fichier local contenant la valeur que vous avez copiée à l'étape [**Copier la clé d'environnement**](/docs/fr/self-hosted-environments-quickstart#set-up-manually) de l'interface utilisateur d'administration, pour que le secret n'apparaisse jamais dans votre historique de shell. Exécutez `(umask 077 && cat > ./environment-secret)`, collez le secret, appuyez sur Entrée, puis Ctrl-D. Ensuite, créez le Secret et supprimez le fichier :
386 491
387```bash theme={null}492```bash theme={null}
388kubectl create secret generic claude-runner-environment-secret -n claude-runners --from-file=environment-secret=./environment-secret493kubectl create secret generic claude-runner-environment-secret -n claude-runners --from-file=environment-secret=./environment-secret
500 Réutiliser un checkout pré-chauffé605 Réutiliser un checkout pré-chauffé
501</h2>606</h2>
502 607
503Pour les grands référentiels, le clone peut dominer le démarrage de la session. À `--capacity 1` sans [hook `checkout`](/docs/fr/self-hosted-environments-configuration#checkout), le runner garde un clone canonique par référentiel à `<base-dir>/<repo-owner>/<repo>` et le réutilise entre les sessions : il récupère la ref demandée, détache `HEAD`, et réinitialise dur à celle-ci, ce qui est quasi-instantané quand peu a changé. Pour sauter le clone froid, fournissez le clone de l'une de deux façons :608Pour les grands dépôts, le clone peut dominer le démarrage de la session. Pour sauter le clone froid, fournissez vous-même un clone au chemin où le runner conserve le sien. Sans [hook `checkout`](/docs/fr/self-hosted-environments-configuration#checkout), le runner garde un clone canonique par dépôt à `<base-dir>/<repo-owner>/<repo>` et le réutilise entre les sessions :
609
610* **À `--capacity 1`** : le runner récupère la ref demandée, détache `HEAD`, et réinitialise dur à celle-ci, ce qui est quasi-instantané quand peu a changé.
611* **À une `--capacity` supérieure à un** : le runner récupère dans ce clone, puis extrait un worktree distinct à partir de celui-ci pour chaque session. Un clone pré-chauffé économise le téléchargement, mais pas le checkout.
612
613Fournissez le clone dans l'image ou sur un volume persistant :
504 614
505* **Clone dans l'image** : construisez le clone dans votre image runner à ce chemin. Chaque conteneur frais démarre alors avec le clone chaud sans réutiliser un disque.615* **Clone dans l'image** : construisez le clone dans votre image runner à ce chemin. Chaque conteneur frais démarre alors avec le clone chaud sans réutiliser un disque.
506* **Clone sur un volume persistant** : sur les runners que vous pré-verrouillez au compte d'un utilisateur avec [`--lock-to-account`](/docs/fr/self-hosted-environments-reference#runner-cli-flags), pointez `--base-dir` vers un volume persistant, pour que le disque ne serve que ce compte. Un runner pré-verrouillé ne récupère jamais les sessions de canal Claude Tag, donc cette option ne s'applique pas aux runners qui les servent.616* **Clone sur un volume persistant** : sur les runners que vous pré-verrouillez au compte d'un utilisateur avec [`--lock-to-account`](/docs/fr/self-hosted-environments-reference#runner-cli-flags), pointez `--base-dir` vers un volume persistant, pour que le disque ne serve que ce compte. Un runner pré-verrouillé ne récupère jamais les sessions de canal Claude Tag, donc cette option ne s'applique pas aux runners qui les servent.
508Ce que le chemin de réutilisation fait et ne garantit pas :618Ce que le chemin de réutilisation fait et ne garantit pas :
509 619
510* **N'importe quelle forme de clone fonctionne** : un clone complet, peu profond, ou à branche unique au chemin est utilisé tel quel. Le runner ne passe jamais `--depth` lors de la récupération dans un clone existant, donc un pré-chauffage complet garde son historique complet et un peu profond reste peu profond. `CLAUDE_RUNNER_FETCH_DEPTH` (`full`, `0`, ou un nombre ; par défaut 50) contrôle uniquement le clone froid que le runner fait quand aucun clone n'existe encore.620* **N'importe quelle forme de clone fonctionne** : un clone complet, peu profond, ou à branche unique au chemin est utilisé tel quel. Le runner ne passe jamais `--depth` lors de la récupération dans un clone existant, donc un pré-chauffage complet garde son historique complet et un peu profond reste peu profond. `CLAUDE_RUNNER_FETCH_DEPTH` (`full`, `0`, ou un nombre ; par défaut 50) contrôle uniquement le clone froid que le runner fait quand aucun clone n'existe encore.
511* **Les changements suivis se réinitialisent, les fichiers non suivis persistent** : chaque session commence à partir d'une réinitialisation dur qui efface les modifications suivies de la session précédente, mais le runner ne lance jamais `git clean`, donc les fichiers non suivis des sessions antérieures du propriétaire verrouillé restent dans l'arbre.621* **Les changements suivis se réinitialisent, les fichiers non suivis persistent** : à `--capacity 1`, chaque session commence à partir d'une réinitialisation dur qui efface les modifications suivies de la session précédente, mais le runner ne lance jamais `git clean`, donc les fichiers non suivis des sessions antérieures du propriétaire verrouillé restent dans l'arbre.
512* **Les répertoires par session persistent aussi** : à côté du checkout, le runner crée des entrées par session sous `<base-dir>/_sessions/` pour chaque session qu'il exécute. Le répertoire de configuration Claude de la session contient une copie locale de la transcription de la conversation. À côté se trouvent les fichiers téléchargés de la session, quand la session en a. Le répertoire de session s'y trouve aussi : il contient tous les worktrees par session et les checkouts du hook `checkout` pendant que la session s'exécute, et il conserve tout ce que Claude a écrit dedans.622* **Les répertoires par session persistent aussi** : à côté du checkout, le runner crée des entrées par session sous `<base-dir>/_sessions/` pour chaque session qu'il exécute. Le répertoire de configuration Claude de la session contient une copie locale de la transcription de la conversation. À côté se trouvent les fichiers téléchargés de la session, quand la session en a. Le répertoire de session s'y trouve aussi : il contient tous les worktrees par session et les checkouts du hook `checkout` pendant que la session s'exécute, et il conserve tout ce que Claude a écrit dedans.
513 623
514 Par défaut, le runner les laisse en place quand la session se termine, donc sur un disque qui survit au processus runner, ils s'accumulent. Chaque session s'exécute en tant qu'utilisateur du runner, donc toute session ultérieure que ce disque sert peut les lire. Si vous conservez un `--base-dir` persistant, dimensionnez le volume pour cette croissance. La même chose s'applique à toute configuration qui redémarre le runner sur le même système de fichiers, y compris la [recette Docker Compose](#docker-compose).624 Par défaut, le runner les laisse en place quand la session se termine, donc sur un disque qui survit au processus runner, ils s'accumulent. Chaque session s'exécute en tant qu'utilisateur du runner, donc toute session ultérieure que ce disque sert peut les lire. Si vous conservez un `--base-dir` persistant, dimensionnez le volume pour cette croissance. La même chose s'applique à toute configuration qui redémarre le runner sur le même système de fichiers, y compris la [recette Docker Compose](#docker-compose).
522 632
523Le processus enfant Claude Code de chaque session exécute le binaire du runner lui-même, et le runner désactive la mise à jour automatique à l'intérieur des sessions qu'il génère, donc chaque session exécute la version que vous avez installée sur l'hôte ou construite dans l'image. Une mise à jour au niveau de l'hôte prend effet la prochaine fois que le runner démarre.633Le processus enfant Claude Code de chaque session exécute le binaire du runner lui-même, et le runner désactive la mise à jour automatique à l'intérieur des sessions qu'il génère, donc chaque session exécute la version que vous avez installée sur l'hôte ou construite dans l'image. Une mise à jour au niveau de l'hôte prend effet la prochaine fois que le runner démarre.
524 634
525Un modèle que vos sessions utilisent peut nécessiter une version plus récente de Claude Code que celle qu'elles exécutent. Le serveur rejette alors les demandes pour ce modèle avec [Claude Code ne supporte pas ce modèle](/docs/fr/errors#claude-code-does-not-support-this-model). Avant d'épingler une version, vérifiez [les versions de Claude Code que les modèles nécessitent](/docs/fr/model-config#available-models) pour chaque modèle que vos sessions utilisent.635Choisissez la version qu'exécutent vos sessions et le moment où elle change :
526 636
637* **Avant d'épingler une version** : vérifiez [les versions de Claude Code que les modèles nécessitent](/docs/fr/model-config#available-models) pour chaque modèle que vos sessions utilisent. Si un modèle nécessite une version plus récente que celle qu'exécutent vos sessions, le serveur rejette les requêtes pour ce modèle avec [Claude Code ne supporte pas ce modèle](/docs/fr/errors#claude-code-does-not-support-this-model).
527* **Pour garder une flotte sur une version** : construisez l'image avec une version épinglée, ou sur un hôte nu installez une version spécifique et [désactivez les mises à jour automatiques](/docs/fr/setup#disable-auto-updates)638* **Pour garder une flotte sur une version** : construisez l'image avec une version épinglée, ou sur un hôte nu installez une version spécifique et [désactivez les mises à jour automatiques](/docs/fr/setup#disable-auto-updates)
528* **Pour mettre à niveau** : installez la version plus récente ou reconstruisez l'image, puis redémarrez les runners639* **Pour mettre à niveau une flotte fixe** : lisez les entrées du [changelog](/docs/en/changelog) entre votre version et celle que vous installez, puis installez la version plus récente ou reconstruisez l'image et redémarrez les runners
640* **Pour mettre à niveau des runners à la demande** : lisez les entrées du [changelog](/docs/en/changelog) entre votre version et celle que vous installez, puis modifiez l'image que démarre votre [hook `spawn-runner`](/docs/fr/self-hosted-environments-configuration#the-spawn-runner-hook). Chaque nouveau runner obtient la nouvelle version. Un runner déjà actif, y compris un runner en attente démarré par [`--min-idle`](/docs/fr/self-hosted-environments-reference#orchestrator-cli-flags), conserve sa version jusqu'à ce qu'il se termine. Ne le redémarrez pas, car son ordre de travail est à usage unique.
529* **Plugins** : les places de marché de plugins ne se mettent pas à jour automatiquement non plus ; définissez `FORCE_AUTOUPDATE_PLUGINS=1` dans l'environnement du runner pour laisser les plugins se mettre à jour automatiquement pendant que le binaire reste épinglé641* **Plugins** : les places de marché de plugins ne se mettent pas à jour automatiquement non plus ; définissez `FORCE_AUTOUPDATE_PLUGINS=1` dans l'environnement du runner pour laisser les plugins se mettre à jour automatiquement pendant que le binaire reste épinglé
530 642
531<h2 id="scale-the-fleet">643<h2 id="scale-the-fleet">
580</h3>692</h3>
581 693
582* **Les sessions reprises perdent le travail non poussé** : un nouveau runner clone à nouveau le dépôt à partir de sa branche de démarrage, donc le travail que la session n'avait pas poussé est perdu.694* **Les sessions reprises perdent le travail non poussé** : un nouveau runner clone à nouveau le dépôt à partir de sa branche de démarrage, donc le travail que la session n'avait pas poussé est perdu.
583 * **Pour conserver le travail commité** : définissez [`--push-outcome-on-release`](/docs/fr/self-hosted-environments-reference#runner-cli-flags). Le runner effectue alors, dans la mesure du possible, un push des branches de résultat de la session avant de la libérer, et la session reprise démarre à partir de ces commits. Les modifications non commitées sont toujours perdues.695 * **Pour conserver le travail commité** : définissez [`--push-outcome-on-release`](/docs/fr/self-hosted-environments-reference#runner-cli-flags) sur chaque runner de l'environnement, car un runner sans ce flag reprend la session à partir de sa branche de démarrage. Un runner avec ce flag effectue, dans la mesure du possible, un push des branches de résultat de la session avant de la libérer, et la session reprise démarre à partir de ces commits. Le push utilise les propres identifiants git de l'hôte runner, y compris sur un runner qui utilise [git géré par Anthropic](#use-the-anthropic-git-proxy). Les modifications non commitées sont toujours perdues.
696 * **Avec un hook `checkout`** : les dépôts extraits via un [hook de cycle de vie `checkout`](/docs/fr/self-hosted-environments-configuration#checkout) ne font pas l'objet d'un push. Créez plutôt un instantané de ces dépôts à partir du [hook `post-session`](/docs/fr/self-hosted-environments-configuration#post-session).
584 * **Avant d'activer le flag** : limitez qui peut pousser vers les refs `claude/*` sur le dépôt distant source. À la reprise, le runner récupère la branche précédemment poussée sans vérifier qui l'a poussée.697 * **Avant d'activer le flag** : limitez qui peut pousser vers les refs `claude/*` sur le dépôt distant source. À la reprise, le runner récupère la branche précédemment poussée sans vérifier qui l'a poussée.
585* **Le clonage d'un dépôt ajouté en milieu de session peut échouer** : Claude le clone avec `git clone` via HTTPS. Sur un runner sans [`--use-anthropic-git-proxy`](#use-the-anthropic-git-proxy), le clonage échoue avec une erreur d'authentification git si rien sur l'hôte ne peut lire le dépôt. Dans la mesure du possible, sélectionnez chaque dépôt dont la session a besoin quand vous la créez.698* **Le clonage d'un dépôt ajouté en milieu de session peut échouer** : Claude le clone avec `git clone` via HTTPS. Sur un runner sans [`--use-anthropic-git-proxy`](#use-the-anthropic-git-proxy), le clonage échoue avec une erreur d'authentification git si rien sur l'hôte ne peut lire le dépôt. Dans la mesure du possible, sélectionnez chaque dépôt dont la session a besoin quand vous la créez.
586* **Certains connecteurs n'apparaissent pas dans les sessions auto-hébergées** : un connecteur que vous n'avez pas encore connecté dans les paramètres claude.ai n'est pas listé dans une session auto-hébergée, et la session ne vous invitera pas à le connecter. Connectez-le d'abord dans les paramètres, puis démarrez une session fraîche. Ajouter un connecteur à une session déjà en cours d'exécution ne rend pas non plus ses outils disponibles à Claude ; démarrez une session fraîche pour récupérer un connecteur nouvellement ajouté.699* **Certains connecteurs n'apparaissent pas dans les sessions auto-hébergées** : un connecteur que vous n'avez pas encore connecté dans les paramètres claude.ai n'est pas listé dans une session auto-hébergée, et la session ne vous invitera pas à le connecter. Connectez-le d'abord dans les paramètres, puis démarrez une session fraîche. Ajouter un connecteur à une session déjà en cours d'exécution ne rend pas non plus ses outils disponibles à Claude ; démarrez une session fraîche pour récupérer un connecteur nouvellement ajouté.
606* **Le runner n'apparaît pas dans l'environnement** : confirmez que l'hôte peut atteindre `api.anthropic.com` sur HTTPS, que le secret de l'environnement est actuel, et que l'horloge de l'hôte est à moins de cinq minutes de l'heure réelle ; un décalage plus grand cause l'échec de l'authentification. Le runner enregistre `[runner:fatal]` avec la raison du rejet en cas d'échec d'authentification.719* **Le runner n'apparaît pas dans l'environnement** : confirmez que l'hôte peut atteindre `api.anthropic.com` sur HTTPS, que le secret de l'environnement est actuel, et que l'horloge de l'hôte est à moins de cinq minutes de l'heure réelle ; un décalage plus grand cause l'échec de l'authentification. Le runner enregistre `[runner:fatal]` avec la raison du rejet en cas d'échec d'authentification.
607* **Le runner quitte au démarrage avec `cannot create or write to base directory`** : le runner ne peut pas créer ou écrire à `--base-dir`, qui par défaut est `/workspace`. Corrigez la propriété du répertoire ou pointez `--base-dir` vers un chemin inscriptible, comme décrit dans [Garder le répertoire de base et la capacité identiques sur tous les runners](#keep-the-base-directory-and-capacity-identical-across-runners). Si le runner enregistre à la place `[runner:fatal]` disant que la vérification du répertoire de base a expiré, le répertoire est sur un montage NFS ou CSI suspendu. Vérifiez la santé du montage plutôt que les permissions. Le runner imprime ces deux échecs de démarrage à stderr avant d'ouvrir `--log-file`, donc cherchez-les dans le terminal ou les journaux de conteneur de votre plateforme plutôt que dans le fichier journal. Avant v2.1.225, le runner ne vérifiait pas le répertoire de base au démarrage, et cette mauvaise configuration échouait les sessions après la récupération à la place.720* **Le runner quitte au démarrage avec `cannot create or write to base directory`** : le runner ne peut pas créer ou écrire à `--base-dir`, qui par défaut est `/workspace`. Corrigez la propriété du répertoire ou pointez `--base-dir` vers un chemin inscriptible, comme décrit dans [Garder le répertoire de base et la capacité identiques sur tous les runners](#keep-the-base-directory-and-capacity-identical-across-runners). Si le runner enregistre à la place `[runner:fatal]` disant que la vérification du répertoire de base a expiré, le répertoire est sur un montage NFS ou CSI suspendu. Vérifiez la santé du montage plutôt que les permissions. Le runner imprime ces deux échecs de démarrage à stderr avant d'ouvrir `--log-file`, donc cherchez-les dans le terminal ou les journaux de conteneur de votre plateforme plutôt que dans le fichier journal. Avant v2.1.225, le runner ne vérifiait pas le répertoire de base au démarrage, et cette mauvaise configuration échouait les sessions après la récupération à la place.
608* **Les sessions restent en attente** : chaque runner en ligne peut être verrouillé à un propriétaire différent. Vérifiez la métrique `claude_code_self_hosted_runner_locked_account` de chaque runner [métrique](/docs/fr/self-hosted-environments-reference#prometheus-metrics) ou le champ `locked_account` de sa ligne de journal `[runner:health]` pour voir qui la détient. Les deux affichent l'email du propriétaire uniquement après que le runner ait reçu un jeton de session portant une réclamation `act.email`, ce qu'une session d'agent Claude Tag ne fait jamais. Sans la réclamation, le runner n'émet aucune série `locked_account` et enregistre `locked_account=yes`, ce qui vous dit que le runner est verrouillé mais pas à quel propriétaire. Ajoutez des répliques, ou attendez qu'un runner existant se draine et redémarre. Si l'environnement utilise des runners à la demande, vérifiez l'orchestrateur à la place ; consultez [Runners à la demande](/docs/fr/self-hosted-environments-configuration#on-demand-runners).721* **Les sessions restent en attente** : chaque runner en ligne peut être verrouillé à un propriétaire différent. Vérifiez la métrique `claude_code_self_hosted_runner_locked_account` de chaque runner [métrique](/docs/fr/self-hosted-environments-reference#prometheus-metrics) ou le champ `locked_account` de sa ligne de journal `[runner:health]` pour voir qui la détient. Les deux affichent l'email du propriétaire uniquement après que le runner ait reçu un jeton de session portant une réclamation `act.email`, ce qu'une session d'agent Claude Tag ne fait jamais. Sans la réclamation, le runner n'émet aucune série `locked_account` et enregistre `locked_account=yes`, ce qui vous dit que le runner est verrouillé mais pas à quel propriétaire. Ajoutez des répliques, ou attendez qu'un runner existant se draine et redémarre. Si l'environnement utilise des runners à la demande, vérifiez l'orchestrateur à la place ; consultez [Runners à la demande](/docs/fr/self-hosted-environments-configuration#on-demand-runners).
609* **Les sessions échouent immédiatement après la récupération** : ouvrez la session dans claude.ai/code pour voir l'erreur. Les causes les plus courantes sont les identifiants git manquants [identifiants git](#configure-git) dans l'image runner et les outils de build qui ne sont pas installés. Un répertoire de base non inscriptible arrête le runner au démarrage au lieu d'échouer les sessions. Consultez l'entrée **Le runner quitte au démarrage avec `cannot create or write to base directory`** dans cette liste.722* **Les sessions échouent immédiatement après la récupération** : ouvrez la session dans claude.ai/code pour voir l'erreur. Les causes les plus courantes sont des [identifiants git](#configure-git) manquants dans l'image runner et les outils de build qui ne sont pas installés. Sur un runner démarré avec `--use-anthropic-git-proxy`, consultez [Quand les sessions ne démarrent pas sur un runner avec le proxy git](#when-anthropic-doesnt-serve-a-session). Un répertoire de base non inscriptible arrête le runner au démarrage au lieu d'échouer les sessions. Consultez l'entrée **Le runner quitte au démarrage avec `cannot create or write to base directory`** dans cette liste.
723* **Les sessions ne démarrent pas sur un runner qui a défini `--use-anthropic-git-proxy`** : cherchez dans le journal du runner `access denied by the git proxy`, ou une erreur git qui nomme une adresse `api.anthropic.com` contenant `/git_proxy/`. Pour déterminer si Anthropic a servi la session et corriger la cause, consultez [Quand les sessions ne démarrent pas sur un runner avec le proxy git](#when-anthropic-doesnt-serve-a-session).
610* **Les sessions ne peuvent pas atteindre le réseau via un proxy de sortie authentifiant** : quand la source que vous avez définie avec [`--proxy-authorization-command` ou `--proxy-authorization-file`](#authenticate-to-an-egress-proxy) échoue, expire après 30 secondes, ou produit une valeur vide, le runner répond à cette connexion `502 Bad Gateway` et enregistre pourquoi. Le runner rédige la stderr de la commande dans ce journal et ne journalise jamais la valeur de l'en-tête. Avec `--proxy-authorization-command`, exécutez la commande vous-même sur l'hôte pour confirmer qu'elle imprime la valeur d'en-tête entière sur stdout. Si le runner quitte à la place au démarrage avec `could not start the proxy-authorization listener`, il ne pouvait pas ouvrir son écouteur de boucle locale.724* **Les sessions ne peuvent pas atteindre le réseau via un proxy de sortie authentifiant** : quand la source que vous avez définie avec [`--proxy-authorization-command` ou `--proxy-authorization-file`](#authenticate-to-an-egress-proxy) échoue, expire après 30 secondes, ou produit une valeur vide, le runner répond à cette connexion `502 Bad Gateway` et enregistre pourquoi. Le runner rédige la stderr de la commande dans ce journal et ne journalise jamais la valeur de l'en-tête. Avec `--proxy-authorization-command`, exécutez la commande vous-même sur l'hôte pour confirmer qu'elle imprime la valeur d'en-tête entière sur stdout. Si le runner quitte à la place au démarrage avec `could not start the proxy-authorization listener`, il ne pouvait pas ouvrir son écouteur de boucle locale.
611* **Le runner enregistre des lignes `Poll failed` contenant `rejecting the malformed poll response`** : le runner a reçu une réponse de sondage dont le corps n'est pas le JSON attendu de la file d'attente, le plus souvent parce que quelque chose entre le runner et `api.anthropic.com`, comme un proxy d'interception ou un portail captif, a répondu avec sa propre page. Le runner rejette la réponse, la compte sous le type `transport` de la [métrique](/docs/fr/self-hosted-environments-reference#prometheus-metrics) `claude_code_self_hosted_runner_poll_errors_total`, et réessaie selon le calendrier de sondage échoué décrit dans [Cycle de vie de la session](/docs/fr/self-hosted-environments#session-lifecycle). Le runner continue de servir ses sessions en direct. Configurez le proxy pour passer les réponses de `api.anthropic.com` inchangées. Avant v2.1.246, le runner lisait une telle réponse comme une file d'attente de travail vide, ce qui pouvait terminer ses sessions en direct ou le faire quitter.725* **Le runner enregistre des lignes `Poll failed` contenant `rejecting the malformed poll response`** : le runner a reçu une réponse de sondage dont le corps n'est pas le JSON attendu de la file d'attente, le plus souvent parce que quelque chose entre le runner et `api.anthropic.com`, comme un proxy d'interception ou un portail captif, a répondu avec sa propre page. Le runner rejette la réponse, la compte sous le type `transport` de la [métrique](/docs/fr/self-hosted-environments-reference#prometheus-metrics) `claude_code_self_hosted_runner_poll_errors_total`, et réessaie selon le calendrier de sondage échoué décrit dans [Cycle de vie de la session](/docs/fr/self-hosted-environments#session-lifecycle). Le runner continue de servir ses sessions en direct. Configurez le proxy pour passer les réponses de `api.anthropic.com` inchangées. Avant v2.1.246, le runner lisait une telle réponse comme une file d'attente de travail vide, ce qui pouvait terminer ses sessions en direct ou le faire quitter.
612* **La branche d'une session n'existe plus sur la télécommande** : pour une source git que la session ne lit que, le runner saute cette source et continue sur les autres. Pour la source vers laquelle la session pousse les résultats, une branche supprimée, généralement parce qu'elle a été fusionnée et supprimée automatiquement, échoue la session avec une erreur nommant le référentiel et la branche et vous demandant de restaurer la branche et de réessayer. Le runner échoue la session avec la même erreur quand sauter laisserait sans référentiel du tout. Avant v2.1.228, une telle session démarrait dans un répertoire vide.726* **La branche d'une session n'existe plus sur la télécommande** : pour une source git que la session ne lit que, le runner saute cette source et continue sur les autres. Pour la source vers laquelle la session pousse les résultats, une branche supprimée, généralement parce qu'elle a été fusionnée et supprimée automatiquement, échoue la session avec une erreur nommant le référentiel et la branche et vous demandant de restaurer la branche et de réessayer. Le runner échoue la session avec la même erreur quand sauter laisserait sans référentiel du tout. Avant v2.1.228, une telle session démarrait dans un répertoire vide.
616 730
617 La vérification d'accès s'exécute à nouveau chaque fois que la session démarre sur un runner, donc une fois que l'identité git du runner a accès en lecture, le prochain démarrage clone le référentiel. Avant v2.1.274, chacun de ces refus échouait le démarrage de la session.731 La vérification d'accès s'exécute à nouveau chaque fois que la session démarre sur un runner, donc une fois que l'identité git du runner a accès en lecture, le prochain démarrage clone le référentiel. Avant v2.1.274, chacun de ces refus échouait le démarrage de la session.
618* **Les sessions prennent des minutes pour démarrer** : le clone initial domine généralement. Regardez la [métrique](/docs/fr/self-hosted-environments-reference#prometheus-metrics) `claude_code_self_hosted_runner_session_init_duration_seconds` pour confirmer, et coupez le clone avec un [checkout pré-chauffé](#reuse-a-pre-warmed-checkout) ou un `CLAUDE_RUNNER_FETCH_DEPTH` plus petit.732* **Les sessions prennent des minutes pour démarrer** : le clone initial domine généralement. Regardez la [métrique](/docs/fr/self-hosted-environments-reference#prometheus-metrics) `claude_code_self_hosted_runner_session_init_duration_seconds` pour confirmer, et coupez le clone avec un [checkout pré-chauffé](#reuse-a-pre-warmed-checkout) ou un `CLAUDE_RUNNER_FETCH_DEPTH` plus petit.
619* **Les tours échouent avec un 401** : chaque session authentifie les appels de modèle avec le [`CLAUDE_CODE_OAUTH_TOKEN`](/docs/fr/self-hosted-environments-configuration#wrapper-scripts) de courte durée que le runner récupère auprès d'Anthropic et fait tourner sur stdin de la session. Quand un tour se termine avec un 401 ou 403 de l'API du modèle, le runner récupère un jeton frais et le transmet à la session. Le tour échoué n'est pas réessayé.733* **Les tours échouent avec un 401** : quand un tour se termine avec un 401 ou 403 de l'API Anthropic, le runner récupère un [`CLAUDE_CODE_OAUTH_TOKEN`](/docs/fr/self-hosted-environments-configuration#wrapper-scripts) frais auprès d'Anthropic et le transmet à la session. Le tour échoué n'est pas réessayé. Ce jeton est de courte durée, et le runner le fait tourner via le stdin de la session.
620 734
621 Quand une récupération échoue, le runner enregistre une ligne `inference_token refresh failed` qui dit quand il réessayera, et il continue à réessayer aussi longtemps que la session s'exécute.735 Quand une récupération échoue, le runner enregistre une ligne `inference_token refresh failed` qui dit quand il réessayera, et il continue à réessayer aussi longtemps que la session s'exécute.
622 736
637 751
638* **Une sortie normale** : le runner a terminé ses sessions et s'est drainé, a atteint son heure de retraite, ou a reçu l'ordre de s'arrêter. Redémarrez-le pour que l'environnement ait à nouveau de la capacité. [Cycle de vie du runner](/docs/fr/self-hosted-environments#runner-lifecycle) décrit ces sorties.752* **Une sortie normale** : le runner a terminé ses sessions et s'est drainé, a atteint son heure de retraite, ou a reçu l'ordre de s'arrêter. Redémarrez-le pour que l'environnement ait à nouveau de la capacité. [Cycle de vie du runner](/docs/fr/self-hosted-environments#runner-lifecycle) décrit ces sorties.
639* **Un démarrage échoué** : le runner ne peut pas démarrer avec la configuration ou l'hôte qui lui a été donné, donc il quitte quelques secondes après son démarrage, et il quitte de la même manière chaque fois que vous le redémarrez. Le redémarrer plus rapidement n'aide pas. Quelqu'un doit lire sa sortie et corriger la cause.753* **Un démarrage échoué** : le runner ne peut pas démarrer avec la configuration ou l'hôte qui lui a été donné, donc il quitte quelques secondes après son démarrage, et il quitte de la même manière chaque fois que vous le redémarrez. Le redémarrer plus rapidement n'aide pas. Quelqu'un doit lire sa sortie et corriger la cause.
754* **Perte de contact** : un runner qui ne peut pas joindre Anthropic pendant plus longtemps que son [bail](/docs/fr/self-hosted-environments#session-lifecycle), par exemple pendant que son hôte est en veille, peut être retiré de l'environnement. Quand un runner retiré se reconnecte, il quitte. Son journal peut afficher une ligne `[runner:fatal]` qui contient `runner record gone server-side` ou, après une panne plus longue, [`poll auth failed`](/docs/fr/self-hosted-environments-quickstart#set-up-an-environment-and-runner). Le runner ne se réenregistre pas de lui-même, donc redémarrez-le.
640 755
641Configurez votre superviseur pour redémarrer le runner chaque fois qu'il quitte, pour attendre plus longtemps entre les redémarrages quand le runner continue de quitter juste après son démarrage, et pour avertir quelqu'un quand cela continue de se produire.756Configurez votre superviseur pour redémarrer le runner chaque fois qu'il quitte, pour attendre plus longtemps entre les redémarrages quand le runner continue de quitter juste après son démarrage, et pour avertir quelqu'un quand cela continue de se produire.
642 757
