Skip to main content
Les environnements auto-hébergés sont en bêta publique sur les plans Team et Enterprise ; un Owner les active en activant Allow self-hosted environments sur la page d’administration Cloud environments. Cette page suppose un runner fonctionnel ; consultez le guide de démarrage rapide pour la configuration et Déployer en production pour les recettes de flotte.
Un environnement auto-hébergé exécute les sessions cloud de Claude Code sur votre propre infrastructure, exécutées par un processus runner que vous déployez. Sans configuration, ce runner clone le référentiel de la session, lance Claude Code et nettoie. Cette page s’adresse à l’ingénieur plateforme qui exploite les runners : elle couvre les points d’extension pour quand ces valeurs par défaut ne conviennent pas, de la fourniture d’identifiants par session au remplacement complet du checkout. Les wrappers et les hooks s’exécutent en tant que fichiers exécutables sur l’hôte runner, qui est Linux ou macOS, et les exemples de cette page supposent un shell POSIX. Quelques variables d’environnement de hook sur cette page utilisent toujours pool, comme CLAUDE_RUNNER_POOL_ID ; les noms de flag CLI et de variable d’environnement utilisent environment, comme --environment-secret-file.

Scripts wrapper

Utilisez un script wrapper quand chaque session a besoin d’une configuration que le runner ne peut pas faire seul : provisionner des identifiants de courte durée limités au créateur de la session, exporter des secrets spécifiques à l’environnement, préparer des chaînes d’outils de langage ou appliquer des limites de ressources autour du processus enfant. Le runner démarre votre wrapper à la place du binaire Claude Code, une fois par session. Terminez le wrapper en exec-ant dans $CLAUDE_RUNNER_CLAUDE_BIN, le binaire du runner lui-même, afin que les signaux et les codes de sortie se propagent correctement. Pointez --exec-path, ou SELF_HOSTED_RUNNER_EXEC_PATH, vers le wrapper quand vous démarrez le runner :
Le runner définit les éléments suivants dans l’environnement du wrapper : Le wrapper hérite également du reste de l’environnement géré de l’enfant, y compris toutes les variables d’environnement fournies par le serveur. exec propage tout automatiquement ; si votre wrapper lance l’enfant d’une autre manière, transmettez l’environnement complet.

Garder stdin et le descripteur de fichier 3 attachés

stdin de l’enfant est le canal de contrôle du runner. Les rotations de token et les signaux de fin de session arrivent dessus. Le runner ouvre également un tuyau sur le descripteur de fichier 3 et lit les signaux d’activité de l’enfant à partir de celui-ci pour piloter les délais d’inactivité et de démarrage. Un simple exec "$CLAUDE_RUNNER_CLAUDE_BIN" "$@" préserve les deux automatiquement. Si votre wrapper met l’enfant en arrière-plan avec un simple &, il coupe stdin de l’enfant : la session semble saine jusqu’à ce que la durée de vie du token OAuth initial d’environ 30 minutes expire, puis chaque appel API échoue avec 401 authentication_error. Si votre wrapper doit mettre l’enfant en arrière-plan, par exemple pour garder un trap de démontage actif, enregistrez stdin sur le descripteur de fichier 4 ou supérieur et réattachez-le explicitement :
Ne fermez pas ou ne réutilisez pas le descripteur de fichier 3 dans le wrapper. Rediriger stdout et stderr de l’enfant est correct.

Provisionner les identifiants limités au créateur de la session

Utilisez la sous-commande decode-token pour lire les revendications du JWT de session. Elle lit le token à partir d’un argument, de CLAUDE_CODE_SESSION_ACCESS_TOKEN ou de stdin, dans cet ordre ; voir Vérifier le token à l’intérieur de la session pour ce qu’elle vérifie. L’exemple ci-dessous décode l’identité du créateur, l’échange contre des identifiants AWS de courte durée et exec dans Claude Code :
Utilisez jq -re plutôt que jq -r quand la revendication extraite contrôle une décision d’authentification, afin qu’une revendication absente se termine avec un code non-zéro au lieu de transmettre la chaîne littérale null en aval. Les sessions créées par une identité de service d’organisation, comme les sessions de bot et d’agent, portent un sujet agent: plutôt que user:, donc cet exemple les refuse ; si votre environnement sert ces sessions, décidez explicitement si le wrapper revient à un identifiant par défaut pour elles au lieu de se terminer. Quand votre échange d’identifiants a besoin du sujet SSO ou de l’email à la place, lisez .act.attested_by.sub ou .act.email et gérez leur absence : le token ne les porte que quand la surface de création les a enregistrés, et une session envoyée par CLI peut manquer les deux. Pour la référence complète des revendications et la vérification à partir de services en dehors du runner, voir Vérifier l’identité de la session.

Hooks de cycle de vie

Les hooks de cycle de vie remplacent les étapes du pipeline par session du runner par vos propres scripts. Pointez le runner vers un répertoire de hooks avec --hooks-dir <path>, ou SELF_HOSTED_RUNNER_HOOKS_DIR. Le runner cherche des fichiers exécutables avec des noms bien connus ; tout hook qui n’est pas présent revient au comportement intégré, donc vous n’écrivez que ceux dont vous avez besoin. Les hooks s’exécutent avec les privilèges du runner lui-même, et les enfants de session partagent cet UID, donc montez le répertoire de hooks en lecture seule, ou intégrez-le à l’image, afin que le code de session ne puisse pas le modifier ; voir la section de durcissement. Ces hooks sont distincts des hooks Claude Code, qui s’exécutent à l’intérieur de la session ; les hooks de cycle de vie s’exécutent sur le runner, autour de la session.

checkout

S’exécute une fois par référentiel, à la place du clone et de la récupération intégrés du runner. Utilisez le hook pour cloner à partir d’un miroir de lecture directe, amorcer un arbre de travail à partir d’une archive ou appliquer une authentification git par session. Le runner définit : Le script doit laisser un arbre de travail à CLAUDE_RUNNER_CHECKOUT_PATH vérifié à la révision demandée. HEAD détaché est correct ; le runner crée la branche de travail de la session par-dessus. Le runner vérifie que le chemin contient un .git après ; si votre hook matérialise une source non-git comme Perforce ou une archive dépaquetée, définissez CLAUDE_RUNNER_SKIP_GIT_VERIFY=1 dans l’environnement du runner pour ignorer cette vérification. Les flux basés sur git comme la création de branche de travail et l’envoi de résultats nécessitent un checkout git, donc exportez les résultats à partir d’arbres non-git avec un hook post-session. Le runner ne transmet pas un identifiant git au hook. À la place, frappez un identifiant de clone par session à partir de l’identité de la session : vérifiez CLAUDE_CODE_SESSION_ACCESS_TOKEN avec une bibliothèque JWT standard par rapport au point de terminaison JWKS sous CLAUDE_RUNNER_API_BASE_URL, comme décrit dans Vérifier le token à partir de votre service, puis faites en sorte que votre service d’identifiants émette un identifiant de clone de courte durée pour l’identité dans la revendication act du token. CLAUDE_RUNNER_CLAUDE_BIN n’est pas défini dans l’environnement du hook de checkout, donc la sous-commande decode-token n’est pas disponible ici. Revenir à tout ce que l’authentification git de l’hôte a déjà, comme un agent SSH, un helper d’identifiants ou .netrc, est aussi une option. Quand le hook se termine avec un code non-zéro, ou se termine avec 0 sans laisser un checkout utilisable derrière, ce que le runner fait dépend du référentiel :
  • Un référentiel vers lequel la session envoie les résultats : le runner échoue la session, et sur une sortie non-zéro affiche la queue du stderr du script à l’utilisateur.
  • Un référentiel que la session lit uniquement, comme un référentiel ajouté à une session en cours d’exécution : le runner enregistre une ligne [runner:warn] avec le détail de l’échec, affiche une étape Skipped à la session, supprime ce que le hook a laissé au chemin de checkout et continue avec les référentiels restants. Quand le runner ne peut pas supprimer le chemin immédiatement, il réessaie la suppression à la fin de la session. Si ignorer laisse la session sans aucun référentiel du tout, le runner échoue la session de toute façon.
Avant v2.1.228, le runner échouait la session sur un échec de hook pour tout référentiel, donc un référentiel en lecture seule que le hook ne pouvait pas servir échouait la session à nouveau sur chaque nouveau runner sur lequel la session reprenait. Le runner supprime le chemin de checkout après la fin de la session.

post-session

S’exécute une fois par session, après la sortie de l’enfant Claude Code et avant que le runner ne démonte l’espace de travail. Ce hook est votre seule chance de sauvegarder le travail non commis : à --capacity au-dessus d’un, le runner supprime les worktrees par session juste après le retour du hook, et à --capacity 1 le clone canonique réutilisé est réinitialisé en dur quand la session suivante démarre, donc les changements suivis non commis ne survivent sur aucun chemin. Les utilisations typiques sont l’envoi d’une branche d’instantané de changements non commis, l’archivage de journaux ou l’émission d’un événement de fin de session à vos propres systèmes. Le hook se déclenche à chaque fin de session où un processus enfant a été généré, quelle qu’en soit la cause ; les valeurs CLAUDE_RUNNER_EXIT_REASON ci-dessous énumèrent les cas. Il ne peut pas se déclencher quand le runner se termine brutalement, comme une préemption de VM ou une perte de courant ; si vous avez besoin de garanties contre une terminaison brutale, prenez des instantanés périodiquement à partir de l’intérieur de la session avec un hook Claude Code PostToolUse à la place. Le runner définit : CLAUDE_RUNNER_EXIT_REASON prend l’une des quatre valeurs :
  • completed : une sortie propre, y compris une session archivée ou supprimée pendant que l’enfant était toujours connecté.
  • failed : un crash enfant ou un échec de configuration après spawn.
  • interrupted : une libération d’inactivité, un délai d’expiration au démarrage, une désassignation du serveur, un drainage ou une suppression de watchdog.
  • abandoned : réservé aux sessions qu’un autre runner a revendiquées ; le hook ne se déclenche actuellement pas dans ce cas.
La sémantique du compteur de cycle de vie de la session classe une libération d’inactivité, un délai d’expiration au démarrage et une désassignation du serveur comme completed à la place : ce sont des remises propres du point de vue de la session même si ce hook les signale comme interrupted. Le statut de sortie du hook n’affecte jamais le résultat de la session ; un échec est enregistré et ignoré. Le runner attend jusqu’à --post-session-hook-timeout-sec, 60 secondes par défaut, à chaque fin de session y compris l’arrêt du runner. Cet exemple sauvegarde le travail non commis dans une branche de secours :
Le hook envoie avec tout ce que les identifiants git disponibles dans son propre environnement sur l’hôte runner. Sous la posture sans identifiants dans l’image, y compris quand le clone intégré passe par le proxy git Anthropic, il n’y en a pas, donc frappez un identifiant de push de courte durée à l’intérieur du hook avant d’envoyer : échangez le token de session que le hook reçoit dans CLAUDE_CODE_SESSION_ACCESS_TOKEN avec votre propre service de token, en le vérifiant comme Vérifier l’identité de la session le décrit. Quand le hook détient un identifiant que la session n’avait pas, épinglez aussi où il envoie : remplacez origin par une URL fournie par l’opérateur et passez -c credential.helper= plus votre propre helper, afin que la configuration au niveau du référentiel que la session a écrite ne puisse pas rediriger l’envoi accrédité.

Timing du hook quand le runner libère une session

Une session libérée peut reprendre sur un autre runner. Sur un runner en v2.1.236 ou ultérieur, ce que la session faisait à la libération décide si elle peut reprendre avant que ce hook se termine :
  • Inactif après un tour, ou expiré au démarrage : le runner arrête l’enfant et exécute ce hook jusqu’à la fin. Ce n’est qu’alors qu’il libère la session. Un message utilisateur envoyé pendant que le hook s’exécute ne peut pas reprendre la session sur un autre runner avant que le hook se termine.
  • En attente que l’utilisateur réponde à une invite, comme une invite de permission : le runner libère d’abord la session, puis exécute ce hook. Un message utilisateur envoyé pendant que le hook s’exécute peut reprendre la session sur un autre runner avant que le hook se termine.
Une libération à l’heure --retire-at suit les mêmes deux chemins. Pendant un drainage SIGTERM, le runner maintient le bail de session jusqu’à ce que le hook se termine ; voir Timing d’arrêt. Avant v2.1.236, le runner libérait d’abord la session puis exécutait ce hook sur les deux chemins.

command

S’exécute une fois par session après le checkout, à la place du spawn enfant intégré. Le hook reçoit le même environnement qu’un script wrapper et doit exec dans "$CLAUDE_RUNNER_CLAUDE_BIN" de la même manière. Utilisez le hook command pour garder toute la personnalisation dans un répertoire de hooks ; utilisez --exec-path quand le wrapper vit ailleurs. Si --exec-path est aussi défini, le flag prend la priorité et le hook command est ignoré. Toujours exec le binaire du runner plutôt qu’un claude résolu par PATH ; sinon vous annulez l’épinglage de version.

Runners à la demande

Au lieu d’exécuter une flotte fixe, vous pouvez démarrer un runner par session. L’orchestrateur est une sous-commande séparée et sans état qui interroge Anthropic pour les demandes de spawn, une par session qui est en attente sans runner disponible, et exécute votre hook spawn-runner pour chacune. Votre hook soumet une charge de travail à votre plateforme : un Kubernetes Job, une instance EC2, un Nomad dispatch. Les runners à la demande améliorent l’hygiène des identifiants. Sur une flotte fixe, le secret d’environnement vit sur chaque hôte runner, qui est le même hôte qui exécute les sessions utilisateur. Avec l’orchestrateur, le secret d’environnement reste uniquement sur l’hôte orchestrateur, qui n’exécute jamais le code utilisateur ; chaque runner généré reçoit un bon de travail à usage unique qui enregistre exactement un runner puis expire. Pour démarrer l’orchestrateur, passez le secret d’environnement et un répertoire de hooks contenant un script spawn-runner exécutable :
L’orchestrateur ne conserve aucun état entre les sondages, donc vous pouvez exécuter deux ou plusieurs répliques contre le même environnement pour la disponibilité. Chaque demande de spawn est revendiquée côté serveur par exactement une réplique. Toutes les répliques doivent utiliser la même valeur --expected-spawn-seconds ; voir le contrat du hook.

Le hook spawn-runner

L’orchestrateur exécute ${hooks-dir}/spawn-runner une fois par demande de spawn. Le hook doit soumettre le travail de manière asynchrone, sans attendre le démarrage du runner, et revenir dans --hook-timeout, 60 secondes par défaut. Le hook reçoit : Le runner généré s’enregistre avec le bon de travail à la place du secret d’environnement :
  • Démarrez-le avec le bon de travail : pointez --environment-secret-file vers un fichier contenant le JWT du bon de travail, ou définissez SELF_HOSTED_RUNNER_ENVIRONMENT_SECRET à la valeur JWT.
  • Copiez le JWT avant la sortie du hook : l’orchestrateur supprime le fichier du bon de travail après la sortie du hook, donc copiez le JWT dans la charge de travail que vous soumettez, comme un Secret Kubernetes sur le Job généré, plutôt que de transmettre le chemin du fichier.
  • Utilisez --capacity 1 sur les runners générés : un bon de travail lié à une session enregistre exactement un runner lié à cette session, donc une capacité plus élevée ajoute des emplacements qui ne reçoivent jamais de travail, et le runner enregistre un avertissement au démarrage.
  • Les bons de travail de pré-réchauffage s’enregistrent sans liaison : le runner de secours n’est pas lié à une session et revendique le travail en attente comme un runner de flotte fixe.
Le contrat a quatre règles agnostiques de l’approvisionneur :
  1. Soyez idempotent sur CLAUDE_RUNNER_ORDER_ID. La redélivraison de la même demande doit générer au maximum un runner. Dérivez un nom de ressource déterministe à partir de l’ID et laissez votre plateforme rejeter le doublon.
  2. Ne réessayez pas la charge de travail. Un ID de commande signifie au maximum une charge de travail créée. Si le runner ne s’enregistre jamais, Anthropic re-demande avec un ID de commande frais après --expected-spawn-seconds.
  3. Utilisez le contrat du code de sortie. Sortie 0 signifie soumis. Sortie 1 signifie échec réessayable ; la session recule et est re-proposée. Sortie 2 ou supérieure signifie non-réessayable ; la session est bloquée du spawning à nouveau jusqu’à ce qu’un Owner sélectionne Retry sur elle dans l’onglet Activity de l’environnement. Sur une sortie non-zéro, la queue du stderr du hook apparaît là comme la raison de l’échec, donc écrivez l’erreur exploitable sur stderr et jamais les secrets. Pour une demande de pré-réchauffage il n’y a pas de session à échouer : l’orchestrateur enregistre une sortie non-zéro localement uniquement, et le serveur re-demande le spawn après le bail.
  4. Définissez --expected-spawn-seconds à au moins votre temps de démarrage p99. C’est le bail côté serveur. Toutes les répliques d’orchestrateur doivent utiliser la même valeur.
Tout ce que le hook écrit sur stdout ou stderr apparaît dans le journal de l’orchestrateur avec les identifiants automatiquement supprimés. Si les sessions restent en attente, vérifiez le corps /healthz de l’orchestrateur pour les compteurs de file d’attente, puis ouvrez l’onglet Activity de votre environnement sur la page d’administration Cloud environments : développez une session échouée là pour son erreur de spawn, et sélectionnez Retry pour la re-demander.

Serveurs MCP

Pour rendre les serveurs MCP disponibles dans chaque session, ajoutez-les au moment de la construction de l’image avec la même commande claude mcp add utilisée sur une installation de bureau. Si votre runner est un processus nu plutôt qu’un conteneur, exécutez la même commande en tant qu’utilisateur du runner sur l’hôte, puis redémarrez le runner : il lit la configuration de l’hôte une fois au démarrage. Le flag --scope user est requis ; le scope local par défaut écrit sous une clé par répertoire que le runner ne sème pas dans les sessions. Par exemple, dans votre Dockerfile :
Le runner prend un instantané de la configuration de l’hôte une fois au démarrage. L’instantané capture la clé mcpServers du .claude.json de l’hôte, qui vit à côté plutôt qu’à l’intérieur de ~/.claude/, et le runner sème uniquement cette clé dans la configuration isolée de chaque session ; l’état du compte et l’historique du projet sont supprimés. Pour confirmer que les serveurs ont atteint les sessions, démarrez une session sur l’environnement et demandez à Claude de lister ses outils MCP ; le runner enregistre également un avertissement de démarrage pour toute entrée capturée dont le type n’est pas reconnu et supprime l’entrée, afin que vous puissiez voir pourquoi ce serveur manque des sessions. Quand SELF_HOSTED_RUNNER_HOST_CONFIG_DIR est défini, le runner lit .claude.json à partir de ce répertoire à la place, donc pointer la variable vers un répertoire vide désactive aussi le semis MCP. Deux autres sources fonctionnent aussi :
  • Le fichier MCP géré au scope d’entreprise](/fr/managed-mcp) à son chemin système standard : /etc/claude-code/managed-mcp.json sur les hôtes runners Linux, /Library/Application Support/ClaudeCode/managed-mcp.json sur les hôtes macOS. Utilisez-le pour les flottes verrouillées où seuls les serveurs listés par l’administrateur peuvent charger. Voir contrôle exclusif avec managed-mcp.json pour les règles de précédence. Quand ce fichier est sur l’hôte runner, Claude Code ignore les serveurs MCP que le plan de contrôle d’Anthropic livre à une session, y compris les connecteurs claude.ai, et les nomme dans un avertissement sur stderr de l’enfant de la session, que le runner enregistre au niveau de journal debug. Avant v2.1.229, ces sessions se terminaient au démarrage avec You cannot dynamically configure MCP servers when an enterprise MCP config is present.
  • <repo>/.mcp.json : scope du projet. Validez le fichier dans le référentiel ; ses serveurs sont pré-approuvés dans les sessions cloud.
Quand la livraison de connecteur est activée pour votre organisation, le plan de contrôle d’Anthropic livre les connecteurs que vous avez configurés sur claude.ai aux sessions créées de manière interactive via la configuration MCP fournie par le serveur, acheminée via api.anthropic.com. Les sessions créées par programmation, comme les envois CLI, ne reçoivent pas la livraison de connecteur ; donnez-leur des serveurs MCP via l’instantané de l’hôte, le fichier MCP géré ou <repo>/.mcp.json à la place. Le token OAuth de l’enfant ne porte pas un scope pour récupérer les connecteurs directement, donc l’enfant ne tente pas cette récupération lui-même ; la livraison est pilotée par le serveur. settings.json et managed-settings.json ne portent pas de définitions de serveur MCP ; il n’y a pas de champ mcpServers de haut niveau dans le schéma des paramètres. Les sessions héritent de l’environnement du runner, donc définissez ENABLE_TOOL_SEARCH là pour contrôler la recherche d’outils MCP pour chaque session qu’un runner génère ; la page MCP couvre les valeurs.

Inviter les sessions à envoyer leur travail

Les sessions hébergées par Anthropic exécutent un hook Stop, le hook Claude Code qui s’exécute quand Claude finit de répondre, qui invite Claude à valider et envoyer son travail. Le runner n’en installe pas. Sans lui, une session qui se termine avec des changements non commis laisse ce travail uniquement sur le disque du runner, et le bouton Create PR dans claude.ai/code reste inactif jusqu’à ce que la branche existe sur le distant. L’implémentation de référence ci-dessous a deux parties. Fusionnez le bloc de paramètres dans ~/.claude/settings.json sur l’hôte runner, que le runner sème dans chaque session, et enregistrez le script comme ~/.claude/hooks/stop-hook-nudge.sh sur l’hôte runner et rendez-le exécutable :
Le hook pousse Claude à valider et envoyer avant la fin de la session, et reste silencieux quand le répertoire n’est pas un référentiel git ou n’a pas de distant.

Permissions et approbation d’outils

Une session auto-hébergée n’a pas de terminal attaché, donc une invite de permission sans réponse bloque le tour jusqu’à ce que l’utilisateur réponde dans l’interface utilisateur. Le plan de contrôle d’Anthropic envoie la liste des outils de chaque session et les règles de permission avec la charge utile de travail ; la configuration par défaut pré-approuve les appels d’outils de routine, y compris Bash, et les sessions cloud pré-approuvent les éditions de fichiers quel que soit le mode. Un appel que rien ne pré-approuve invite via l’interface utilisateur de la session.
Épinglez uniquement le mode auto sur un environnement dont les conteneurs de session s’exécutent avec sortie réseau par défaut-refuser et le reste de la section de durcissement en place. Les appels d’outils de routine, y compris les demandes réseau Bash, s’exécutent sans un humain dans la boucle sur l’ensemble d’outils pré-approuvés par défaut et en mode auto, donc la limite réseau est ce qui limite où ces appels peuvent atteindre.
Pour garder les invites au minimum quel que soit ce que le plan de contrôle envoie, épinglez le mode auto à partir de votre script wrapper ou du hook command. Le mode auto permet aux sessions de s’exécuter sans invites de permission de routine : un modèle de classificateur séparé examine les actions avant qu’elles ne s’exécutent et bloque celles qu’il rejette, et les règles d’ask explicites forcent toujours une invite ; la page des modes de permission couvre ce que le classificateur vérifie. Le runner ajoute les flags calculés par le serveur avant d’invoquer le wrapper, et pour les flags à valeur unique comme --permission-mode l’analyseur honore la dernière occurrence, donc un flag que vous ajoutez après "$@" remplace la valeur envoyée par le serveur :
Pour pré-approuver des outils spécifiques à la place, ajoutez --allowed-tools avec vos règles, par exemple --allowed-tools "Bash(bazel *) Bash(yarn *) mcp__internal__*". Les flags de liste comme --allowed-tools et --disallowed-tools s’accumulent entre les occurrences plutôt que de se remplacer, donc vos règles s’appliquent en plus de toutes les règles que le plan de contrôle envoie. Pour réduire, ajoutez --disallowed-tools, qui refuse les outils même si une autre règle les permet.

Comment la configuration de chaque session est assemblée

Le runner donne à chaque session son propre répertoire de configuration, semé à partir d’un instantané en mémoire du ~/.claude/ de l’hôte que le runner capture une fois au démarrage : settings.json, CLAUDE.md, hooks, agents, commandes et skills dans votre image runner s’appliquent à chaque session comme la ligne de base au niveau utilisateur. Parce que l’instantané est pris au démarrage, les changements de configuration sur un hôte en cours d’exécution ne prennent effet qu’après un redémarrage du runner. Définissez SELF_HOSTED_RUNNER_HOST_CONFIG_DIR pour semer à partir d’un chemin différent, ou pointez-le vers un répertoire vide pour désactiver le semis. Le .claude/settings.json validé dans le référentiel se superpose comme paramètres du projet. Les sessions lisent également managed-settings.json à partir du chemin système standard dans votre image runner. Que ses clés s’appliquent aux côtés des paramètres gérés par le serveur suit comment Claude Code combine les sources gérées : par défaut, quand votre organisation livre des clés gérées par le serveur, les sessions ignorent le fichier de l’image runner à part les clés que Claude Code lit à partir de chaque source d’administration, comme le bloc env, les verrous de sandbox, les chemins binaires de sandbox et forceRemoteSettingsRefresh. Voir précédence des paramètres. Quand le plan de contrôle d’Anthropic fournit une session avec des hooks Claude Code, le runner les installe aux côtés, pas par-dessus, votre propre configuration. Nécessite Claude Code v2.1.229 ou ultérieur.
  • Où ils atterrissent : le runner écrit chaque script de hook fourni dans un sous-répertoire réservé hooks/.ccr-launcher/ du répertoire de configuration de la session et enregistre les scripts dans un fichier de paramètres séparé qu’il transmet à la session avec --settings, laissant le settings.json semé et vos propres scripts à hooks/<name> intacts. Le runner recrée le sous-répertoire réservé pour chaque session et ne sème pas le contenu de l’hôte à ~/.claude/hooks/.ccr-launcher/ dans les sessions.
  • Qui les crée : le plan de contrôle remplit les scripts à partir de constantes fixes dans son propre déploiement, jamais à partir d’entrées par session ou tierces.
  • Ce qui les gouverne toujours : les hooks livrés via --settings entrent dans la configuration de hook fusionnée ordinaire, pas le niveau géré, donc vos paramètres gérés s’appliquent toujours. disableAllHooks les désactive, et ils ne font pas partie des catégories que allowManagedHooksOnly garde chargées.

Règles de permission validées dans le référentiel

Ne mettez pas une entrée "Edit", "Write" ou "NotebookEdit" nue dans un permissions.allow validé dans le référentiel. Une règle d’outil de fichier nue correspond à l’outil quel que soit le chemin, accordant des écritures n’importe où sur l’hôte plutôt que uniquement l’espace de travail, donc la garde de confinement de portée d’écriture du runner signale la session ; avec --confine-repo-settings enforce elle refuse de générer la session au lieu de consigner et continuer. Voir la section de durcissement. Un référentiel n’a besoin d’aucune règle d’outil de fichier du tout : les sessions cloud pré-approuvent les éditions de fichiers quel que soit le mode. Si vous validez une règle, limitez-la à l’espace de travail, comme "Edit(/**)"; une seule barre oblique de début est relative à la racine du projet, qui est l’espace de travail de la session. Les règles d’outil de fichier nues sont correctes dans le settings.json au niveau de l’hôte de l’opérateur, puisque ce fichier n’est pas validé dans le référentiel. Un defaultMode de auto n’est honoré que à partir du fichier de paramètres au niveau de l’image ou au niveau utilisateur, donc un référentiel extrait ne peut pas se donner le mode auto. Pour les modes que les sessions cloud acceptent et la syntaxe complète des règles, voir modes de permission.

Prochaines étapes