Configurer les environnements cloud

Configurez les environnements cloud pour les sessions Claude Code cloud : niveaux d'accès réseau, variables d'environnement, scripts de configuration et mise en cache d'environnement.

Chaque session cloud s'exécute dans un environnement cloud. Vous pouvez configurer un environnement pour autoriser ou refuser l'accès réseau, définir des variables d'environnement pour la session, sur les plans Pro et Max stocker des identifiants API que les sessions utilisent sans les voir, et exécuter un script de configuration avant que Claude ne commence à travailler.

Les mêmes environnements s'appliquent partout où vous démarrez une session cloud : l'application de bureau, l'application mobile Claude, votre navigateur sur claude.ai/code, le terminal avec claude --cloud, les routines et Claude Tag. Chacune de ces surfaces peut également router vers un environnement auto-hébergé. La section Disponibilité et limitations couvre ce que Claude ne peut pas encore utiliser quand une session Claude Tag s'exécute dans un.

L'environnement par défaut

Si vous n'avez pas encore d'environnement, l'intégration configure l'environnement Default pour vous. Cela dépend de l'endroit où vous vous intégrez :

• Flux CLI tels que /web-setup : créent Default pour vous
• Intégration web sur Pro et Max : crée Default pour vous
• Intégration web sur Team et Enterprise : affiche un formulaire Créer votre premier environnement cloud sauf si un propriétaire a activé la Configuration web rapide ; conservez les valeurs par défaut du formulaire et cliquez sur Créer et terminer pour obtenir le même environnement Default

Default n'a aucune configuration propre :

• Accès réseau Trusted : les sessions atteignent les registres de paquets et autres domaines autorisés, et rien d'autre via le réseau de la session.
• Aucune autre configuration : Default ne définit aucune variable d'environnement ou script de configuration, donc les sessions commencent avec juste les outils pré-installés.

Avec seulement Default disponible, chaque session s'exécute dedans. Quand vous avez plus d'un environnement, les sessions en choisissent un par surface :

• Sur l'application Desktop, l'application mobile et sur claude.ai/code, les sessions que vous démarrez vous-même utilisent l'environnement affiché dans le sélecteur. Un environnement par défaut défini par un propriétaire remplit la sélection quand vous n'en avez pas choisi un. Les threads dans un projet utilisent l'environnement défini dans les paramètres du projet à la place.
• Depuis le CLI, Claude Code utilise votre choix /remote-env, ou revient à l'environnement hébergé par Anthropic quand votre liste en a un, et sinon au premier environnement de votre liste qui n'est pas un environnement bridge, une entrée Remote Control que vous enregistrez pour représenter votre propre machine plutôt qu'un environnement cloud. Pour un environnement auto-hébergé, passer --environment <environment-id> avec son ID ccpool_ quand vous lancez une session remplace le choix /remote-env et le fallback pour cet appel. Claude Code rejette les IDs env_ hébergés par Anthropic passés au drapeau, donc utilisez /remote-env pour cibler ceux-ci. Le drapeau nécessite Claude Code v2.1.224 ou ultérieur.

Configurez un environnement quand le défaut ne suffit pas : quand Claude doit atteindre des domaines en dehors de la liste d'autorisation par défaut, a besoin de variables d'environnement définies pour ses sessions, ou a besoin de dépendances installées avant de commencer à travailler.

Configurer votre environnement

Créez, modifiez et archivez des environnements à partir du sélecteur d'environnement, accessible sur claude.ai/code après l'intégration web, ou à partir de la zone de message dans l'application de bureau. Les environnements que vous créez sont personnels à votre compte ; les environnements partagés créés par un propriétaire apparaissent dans le même sélecteur. Consultez Outils installés pour voir ce qui est disponible sans aucune configuration.

1

Ouvrir le sélecteur d'environnement

Sur claude.ai/code, sélectionnez l'icône cloud affichant le nom de l'environnement actuel, dans la ligne au-dessus de la zone de message. Il n'y a pas de page de paramètres ou d'URL directe pour le sélecteur.

2

Ajouter ou modifier un environnement

Sélectionnez Add cloud environment, ou survolez un environnement existant et sélectionnez l'icône de paramètres qui apparaît à droite. La boîte de dialogue inclut le nom, le niveau d'accès réseau, les variables d'environnement et le script de configuration. Lorsque vous modifiez un environnement cloud existant sur un plan Pro ou Max, la boîte de dialogue inclut également les identifiants API.

Définir les variables d'environnement

Les variables d'environnement utilisent le format .env, une paire KEY=value par ligne. Les valeurs simples n'ont pas besoin de guillemets, et si vous mettez une valeur entre guillemets avec une paire correspondante, les guillemets ne font pas partie de la valeur. Mettez entre guillemets une valeur qui s'étend sur plusieurs lignes ou contient un # : dans une valeur sans guillemets, # démarre un commentaire et le reste de la ligne est supprimé.

L'exemple suivant définit trois variables.

NODE_ENV=development
LOG_LEVEL=debug
DATABASE_URL=postgres://localhost:5432/myapp

Chaque session copie les valeurs de l'environnement une fois, au démarrage, dans des variables d'environnement ordinaires que toute commande exécutée par Claude peut lire. Comme les sessions en cours d'exécution ne relisent pas la configuration, la modification ou l'ajout de variables affecte les sessions que vous démarrez par la suite ; les sessions déjà en cours d'exécution conservent les valeurs avec lesquelles elles ont démarré.

Une session cloud définit également certaines variables elle-même au démarrage. Pour CLAUDE_AUTOCOMPACT_PCT_OVERRIDE, la valeur que la session définit remplace celle que vous ajoutez ici, donc ajouter cette clé ici n'a aucun effet.

Quiconque utilise l'environnement peut lire les valeurs. Sur les plans Pro et Max, utilisez plutôt une identifiant API pour une clé que le proxy d'agent peut joindre à une demande. Les demandes qui ne reçoivent jamais d'identifiant sont listées là.

Ajouter des identifiants API

Un identifiant API est une clé API ou un jeton que vous stockez sur un environnement cloud afin que Claude puisse appeler cette API à partir de n'importe quelle session dans l'environnement sans voir la clé. Le proxy d'agent d'Anthropic ajoute la clé aux demandes pour les hôtes que vous listez, après que chaque demande quitte la VM de la session. La clé n'atteint jamais Claude, les commandes qu'il exécute, ou les variables d'environnement de la session.

Les identifiants API sont disponibles sur les plans Pro et Max. Ils ne sont pas encore disponibles sur les plans Team ou Enterprise, donc la section API credentials n'apparaît pas dans la boîte de dialogue d'environnement sur ces plans.

Exigences

Deux d'entre elles décident si vous pouvez ajouter un identifiant, et deux décident si le proxy d'agent peut l'utiliser une fois ajouté :

• Rôle : un rôle d'administrateur d'organisation dans votre organisation claude.ai
  • Sur Team et Enterprise, les propriétaires le détiennent et les administrateurs ne le détiennent pas
  • Sur Pro et Max, vous le détenez dans votre propre organisation
  • Sans lui, vous voyez une note au lieu de la liste des identifiants, même sur vos propres environnements. Demandez à un propriétaire d'ajouter l'identifiant à un environnement partagé et d'exécuter vos sessions là
• Type d'environnement : un environnement cloud hébergé par Anthropic qui existe déjà. Un environnement auto-hébergé n'a pas d'identifiants API
• Accessibilité de l'API : l'API accepte les connexions depuis Internet, car les demandes partent du réseau d'Anthropic
• Clés de chiffrement : si votre organisation utilise des clés de chiffrement gérées par le client, vous ne pouvez pas enregistrer les identifiants

Ajouter un identifiant

Vous ajoutez les identifiants un à la fois à partir de l'éditeur d'un environnement qui existe déjà. La boîte de dialogue pour un nouvel environnement ne les propose pas. Il n'y a pas non plus de modification. Pour modifier les hôtes ou la valeur d'un identifiant, supprimez-le et ajoutez-le à nouveau.

Pour confirmer que l'identifiant fonctionne, démarrez une session dans l'environnement et demandez à Claude d'appeler l'API, par exemple avec curl. L'API répond comme si la clé était dans la demande, et la clé n'apparaît pas dans les variables d'environnement de la session ou dans aucun fichier. Si la liste marque un identifiant Not sent à la place, la note sous celui-ci explique pourquoi et quoi faire. Deux identifiants dont les hôtes se chevauchent sans correspondre exactement ne reçoivent aucun marqueur, et le proxy d'agent n'en envoie qu'un.

Quelles demandes reçoivent l'identifiant

Le proxy d'agent joint un identifiant à une demande lorsque l'hôte de la demande correspond à l'un de ceux que vous avez listés sur cet identifiant. Les sessions peuvent atteindre ces hôtes même lorsque le niveau d'accès réseau de l'environnement ne le permettrait pas autrement, sauf les hôtes qui ne reçoivent jamais l'identifiant. L'identifiant s'applique dans chaque session qui s'exécute dans l'environnement, peu importe qui l'a démarrée, jusqu'à ce que vous le supprimiez.

Demandes qui ne reçoivent jamais l'identifiant

Le proxy d'agent ne joint jamais un identifiant que vous ajoutez à ces demandes :

• GitHub : le proxy GitHub authentifie les demandes à GitHub à la place, donc vous n'avez pas besoin d'un identifiant API pour cela
• L'API Anthropic et les registres de paquets publics : api.anthropic.com, registry.npmjs.org, jsr.io, npm.jsr.io, pypi.org, files.pythonhosted.org, index.crates.io, et proxy.golang.org
• Demandes de script de configuration : Claude Code se connecte au proxy d'agent au lancement, après l'exécution du script de configuration

Sélectionner un environnement à partir de la CLI

Exécutez /remote-env dans votre terminal pour choisir l'environnement par défaut pour les sessions cloud que vous créez à partir de la CLI, comme claude --cloud. La commande ouvre un sélecteur de vos environnements existants et enregistre votre choix dans la clé remote.defaultEnvironmentId dans vos paramètres utilisateur, donc cela s'applique dans chaque projet sur votre machine jusqu'à ce que vous le changiez, sauf si la même clé est définie à une couche de paramètres de précédence plus élevée, comme les paramètres de projet d'un dépôt.

Un ID d'environnement auto-hébergé, qui a la forme ccpool_..., suit une règle de source plus stricte. Consultez remote.defaultEnvironmentId pour les couches de paramètres que Claude Code honore.

/remote-env définit uniquement la valeur par défaut : il ne démarre pas une session, et il ne peut pas ajouter ou modifier des environnements. Gérez-les à partir du sélecteur d'environnement.

Archiver un environnement

Pour archiver l'un de vos propres environnements, ouvrez-le pour modification et sélectionnez Archive. Un propriétaire archive un environnement partagé à partir de la page Cloud environments dans les paramètres d'administration. Vous ne pouvez pas supprimer un environnement, seulement l'archiver.

L'archivage affecte les nouvelles sessions, pas les sessions en cours d'exécution :

• Les sessions déjà en cours d'exécution dans l'environnement continuent de fonctionner.
• L'environnement disparaît du sélecteur et de /remote-env, donc vous ne pouvez pas le choisir pour les nouvelles sessions.
• Les identifiants API sur l'environnement restent attachés dans ses sessions en cours d'exécution. Supprimez ceux que vous ne voulez plus avant d'archiver.
• Aucune nouvelle session ne peut démarrer dans un environnement archivé, sur aucune surface. Si l'environnement était votre défaut CLI enregistré, Claude Code démarre les sessions cloud CLI dans l'environnement hébergé par Anthropic lorsque votre liste en a un, et sinon dans le premier environnement de votre liste qui n'est pas un environnement de pont Remote Control. Tout ce qui est configuré avec l'environnement explicitement, comme une routine, ne peut pas démarrer de nouvelles sessions dedans. Pointez-le vers un autre environnement.

Environnements partagés par l'organisation

Sur les plans Team et Enterprise, un propriétaire peut créer des environnements cloud qui sont partagés avec chaque membre de l'organisation. Le même rôle gère tout le reste sur la page d'administration Cloud environments, y compris les environnements auto-hébergés ; le rôle Admin ne peut pas ouvrir la page. La liste complète des rôles qui peuvent l'ouvrir est celle pour gérer les paramètres gérés par le serveur.

Les environnements partagés apparaissent dans le sélecteur d'environnement de chaque membre sous un en-tête Organization, après les environnements du membre sous Personal, donc une équipe peut standardiser sur une configuration au lieu que chaque membre la recréé. Sélectionner l'icône de paramètres d'un environnement partagé là ouvre un résumé en lecture seule de sa configuration pour chaque membre, propriétaires inclus.

Un propriétaire rend un environnement disponible pour l'organisation de l'une de deux façons :

• Créer un environnement partagé : utilisez la page Cloud environments dans les paramètres d'administration, qui est aussi où les propriétaires modifient et archivez les environnements partagés. Chacun a un nom, un niveau d'accès réseau, des variables d'environnement au format .env, et un script de configuration.
• Partager un environnement personnel : ouvrez l'un de vos propres environnements pour modification dans le sélecteur d'environnement, puis partagez-le à partir de la ligne Who can use it. L'environnement conserve son ID, donc les sessions et routines qui l'utilisent déjà ne sont pas affectées, et chaque membre peut alors le voir et démarrer des sessions dedans.

Les propriétaires choisissent l'environnement par défaut de l'organisation séparément, sur claude.ai/admin-settings/claude-code.

Les sessions de chaque membre dans un environnement partagé lisent ses variables, donc n'incluez pas de secrets dedans. Les identifiants API, qui donnent aux sessions une clé qu'elles ne peuvent pas lire, ne sont pas encore disponibles sur les plans Team ou Enterprise.

Définir l'environnement qu'un canal Claude Tag utilise

Dans les canaux Claude Tag, Claude fonctionne comme l'identité partagée de votre organisation, pas comme un membre, donc les sessions de canal utilisent uniquement les environnements au niveau de l'organisation, soit les environnements partagés, soit les environnements auto-hébergés. Pour donner à un canal une chaîne d'outils qui n'est pas pré-installée, comme .NET, un propriétaire peut créer un environnement partagé à partir de la page d'administration Cloud environments avec un script de configuration qui l'installe. Pointez le canal vers un environnement de l'une de deux façons :

• Définissez un environnement partagé ou auto-hébergé comme l'environnement par défaut de l'organisation sur claude.ai/admin-settings/claude-code.
• Épinglez-en un à un canal dans les paramètres d'administration Claude Tag.

Accès réseau

Chaque environnement définit un niveau d'accès réseau, qui contrôle les connexions sortantes que ses sessions peuvent établir. Le niveau par défaut, Trusted, autorise les registres de paquets et autres domaines autorisés ; Custom utilise votre propre liste de domaines.

Pour modifier l'accès réseau d'un environnement, ouvrez-le pour l'édition et utilisez le sélecteur Network access dans la boîte de dialogue. Un environnement partagé s'ouvre en lecture seule là, donc un propriétaire modifie son accès réseau à partir de la page Cloud environments dans les paramètres d'administration à la place. L'icône cloud qui ouvre le sélecteur apparaît sur les surfaces de l'application listées sous The Default environment et dans l'éditeur de routines ; les environnements personnels n'ont pas de page séparée dans les paramètres de votre compte claude.ai.

Niveaux d'accès

Le champ Network access dans la boîte de dialogue d'environnement prend l'un des quatre niveaux suivants :

Quel que soit le niveau que vous choisissez, les sessions peuvent toujours atteindre ceux-ci, car chacun emprunte un chemin qui ne passe pas par la liste d'autorisation réseau de la session :

• GitHub, via son proxy séparé
• Les connecteurs MCP que vous activez, dont le trafic transite par les serveurs d'Anthropic
• Les hôtes que vous avez listés sur les identifiants API de l'environnement, sauf les hôtes qui ne reçoivent jamais l'identifiant
• L'API Anthropic, pour les propres requêtes de Claude Code, même au niveau None, comme noté sous Security and isolation

Autoriser des domaines spécifiques

Pour autoriser des domaines qui ne figurent pas dans la liste Trusted, sélectionnez Custom dans les paramètres d'accès réseau de l'environnement, puis listez un domaine par ligne dans le champ Allowed domains. Cet exemple autorise trois hôtes qu'un projet interne pourrait nécessiter.

api.example.com
*.internal.example.com
registry.example.com

Les sessions dans cet environnement peuvent maintenant atteindre api.example.com, n'importe quel sous-domaine de internal.example.com, et registry.example.com, et aucun autre domaine via le réseau de la session. Le trafic GitHub, le trafic des connecteurs MCP, et les requêtes vers les hôtes des identifiants API de l'environnement, autres que les hôtes qui ne reçoivent jamais l'identifiant, ne passent pas par cette liste d'autorisation. Un *. au début correspond à tous les sous-domaines. Pour conserver également les domaines Trusted, cochez Also include default list of common package managers ; laissez-le décoché pour autoriser uniquement ce que vous listez.

Si votre organisation utilise les artifacts, vous n'avez pas besoin de *.frame.claudeusercontent.com dans la liste pour que les sessions les lisent. Lorsque la liste omet cet hôte, Claude Code lit le contenu des artifacts via la connexion de la session à Anthropic à la place. Conservez l'hôte dans une liste d'autorisation dans deux situations :

• Les sessions dans cet environnement ouvrent les artifacts publics d'une autre organisation : Claude Code les récupère directement depuis l'hôte, donc ajoutez-le à cette liste.
• Vous configurez le CLI local ou un runner auto-hébergé : conservez l'hôte dans cette liste d'autorisation. Voir network access requirements et les network requirements auto-hébergées.

Chaque environnement a sa propre liste de domaines autorisés ; il n'y a pas de liste d'autorisation au niveau de l'organisation que les administrateurs peuvent pousser aux environnements de chaque membre. Les paramètres gérés par le serveur s'appliquent toujours dans les sessions cloud, mais aucun d'eux n'ajoute de domaines à la liste d'autorisation réseau de l'environnement. Pour donner à une équipe une liste standard, un propriétaire peut créer un environnement partagé au niveau de l'organisation avec un accès réseau Custom et cette liste.

Proxy GitHub

Dans les environnements hébergés par Anthropic, toutes les opérations GitHub passent par un proxy dédié qui garde vos véritables identifiants GitHub en dehors de la VM de la session, indépendamment du niveau d'accès de l'environnement. Les sessions dans un environnement auto-hébergé authentifient les opérations git avec les identifiants que votre déploiement fournit ; Configure git couvre les options, y compris les identifiants émis par session et un opt-in pour ce même proxy. Le proxy fournit :

• Identifiants Git : le client git à l'intérieur de la VM utilise un identifiant limité en portée, que le proxy vérifie et échange contre votre véritable token GitHub.
• Requêtes API : les requêtes des outils GitHub intégrés, et de gh sous l'espace réservé proxy-injected, sortent avec vos véritables identifiants substitués.
• Protection contre les push : git push fonctionne uniquement contre la branche de travail actuelle de la session ; le clonage, la récupération et les opérations PR fonctionnent normalement.
• Portée du référentiel : les requêtes API GitHub et les requêtes d'actifs de version n'atteignent que les référentiels attachés à la session, donc un script de configuration qui télécharge des actifs de version à partir d'un référentiel non attaché reçoit un 403.
• Restrictions GraphQL : le proxy ne sert qu'un ensemble épinglé d'opérations GraphQL pour les flux de travail de pull-request. Le proxy rejette tout le reste sur le point de terminaison GraphQL avec un 403 qui dit This GraphQL query is not enabled for this session et nomme le fallback REST, gh api repos/{owner}/{repo}/.... La restriction s'applique à chaque requête via le proxy quel que soit l'identifiant que vous fournissez, donc un GH_TOKEN que vous définissez reçoit le même 403. Claude ne peut pas atteindre les API GitHub qui n'existent que dans GraphQL, comme Projects v2, via le proxy.

Les fichiers validés des référentiels publics arrivent via raw.githubusercontent.com, que le proxy de sécurité gère à la place. Ce domaine figure dans la liste Trusted par défaut, donc ces fichiers restent accessibles sauf si le niveau d'accès de l'environnement l'exclut.

Proxy de sécurité

Les sessions cloud dans les environnements hébergés par Anthropic s'exécutent derrière un proxy réseau HTTP/HTTPS à des fins de sécurité et de prévention des abus ; dans un environnement auto-hébergé, le trafic sortant quitte via votre propre limite réseau à la place. Tout le trafic Internet sortant d'une session hébergée par Anthropic passe par ce proxy, qui fournit :

• Protection contre les requêtes malveillantes
• Limitation de débit et prévention des abus
• Filtrage de contenu pour une sécurité renforcée
• Un journal d'audit au niveau DNS des noms d'hôtes demandés

Ce qui est disponible dans les sessions cloud

Dans les environnements hébergés par Anthropic, chaque session obtient une machine virtuelle (VM) fraîche exécutant Ubuntu 24.04 sur x86_64, quel que soit votre propre système d'exploitation et architecture CPU, avec votre dépôt cloné et les chaînes d'outils courantes pré-installées. Quand une dépendance fournit des binaires précompilés, comme les gems Ruby avec des extensions natives ou les roues Python précompilées, utilisez sa compilation Linux x86_64 pour correspondre à la VM. Cette section couvre les défauts hébergés par Anthropic, les outils GitHub intégrés, comment exécuter des tests et des services, et les limites de ressources que chaque VM obtient.

Ce qui est reporté de votre configuration

Les sessions cloud commencent à partir d'un clone frais de votre dépôt. Tout ce que vous validez dans le dépôt est disponible. Tout ce que vous avez installé ou configuré seulement sur votre propre machine n'est pas disponible dans la session. La politique de votre organisation arrive séparément via les paramètres gérés par le serveur.

Pour rendre votre propre configuration disponible dans les sessions cloud, validez-la dans le dépôt.

Quiconque utilise l'environnement peut lire ses variables d'environnement et son script de configuration. La note de la boîte de dialogue sous Environment variables le dit et avertit contre l'ajout de secrets dedans. Sur les plans Pro et Max, stockez une clé que le proxy d'agent peut joindre en tant qu'identifiant API à la place.

Outils installés

Les sessions cloud sont livrées avec les runtimes de langage courants, les outils de construction et les bases de données pré-installés. Le tableau ci-dessous résume ce qui est inclus par catégorie.

¹ Bun est installé mais a des problèmes de compatibilité proxy connus pour la récupération de paquets.

Pour obtenir les versions de la plupart des outils de ce tableau, demandez à Claude d'exécuter check-tools dans une session cloud. C'est une commande shell installée sur la VM de la session, pas une commande que vous tapez avec / ; vous demandez à Claude car Claude exécute toutes les commandes VM pour vous. Pour un outil qu'il ne rapporte pas, comme Ruby, PHP, bun, PostgreSQL ou Redis, demandez à Claude d'exécuter la propre commande de version de l'outil, par exemple psql --version.

Les versions de Node.js sont installées sur /opt/node20, /opt/node21 et /opt/node22, avec 22 sur PATH par défaut. Pour travailler avec une version différente, demandez à Claude de préfixer le répertoire bin de cette version, comme /opt/node20/bin, à PATH.

Les chaînes d'outils en dehors de cette liste, comme le SDK .NET, ne sont pas pré-installées même quand leurs registres de paquets sont sur la liste d'autorisation par défaut. Installez-les avec un script de configuration.

Travaillez avec les problèmes et les demandes de tirage GitHub

Les sessions cloud incluent des outils GitHub intégrés qui permettent à Claude de lire les problèmes, de lister les demandes de tirage, de récupérer les diffs et de publier des commentaires sans aucune configuration. Ces outils s'authentifient via le proxy GitHub en utilisant la méthode que vous avez configurée sous Options d'authentification GitHub, donc votre jeton ne pénètre jamais dans le conteneur.

Vous pouvez définir GH_TOKEN ou GITHUB_TOKEN vous-même dans les paramètres d'environnement, ou laisser les deux non définis et laisser le proxy GitHub s'authentifier pour vous :

• Si vous définissez un jeton, il passe au conteneur inchangé, donc vos scripts et le gh CLI de GitHub l'utilisent directement.
• Si vous ne définissez ni l'un ni l'autre et que le proxy GitHub gère l'authentification pour votre session, les deux variables lisent comme la chaîne d'espace réservé proxy-injected dans les commandes que Claude exécute, et le proxy substitue vos vrais identifiants sur les requêtes GitHub sortantes. gh fonctionne sans un jeton de votre côté, mais un script qui lit GITHUB_TOKEN directement obtient l'espace réservé, pas un jeton utilisable.

Un jeton que vous définissez est une variable d'environnement ordinaire, donc quiconque utilise l'environnement peut le lire ; le chemin du proxy garde l'identifiant hors de la configuration de l'environnement et de la VM de la session.

Pour vérifier quel cas s'applique à votre session, demandez à Claude d'exécuter echo $GH_TOKEN.

Le gh CLI de GitHub est pré-installé. Si vous avez besoin d'une commande gh que les outils intégrés ne couvrent pas, comme gh release ou gh workflow run, demandez à Claude de l'exécuter. gh lit GH_TOKEN automatiquement, donc vous n'avez pas besoin d'exécuter gh auth login.

Liez la sortie à la session

Chaque session cloud a une URL de transcription sur claude.ai, et la session peut lire son propre ID à partir de la variable d'environnement CLAUDE_CODE_REMOTE_SESSION_ID. Utilisez ceci pour mettre un lien traçable dans les corps PR, les messages de validation, les publications Slack ou les rapports générés afin qu'un examinateur puisse ouvrir l'exécution qui les a produits.

Les validations que Claude crée dans une session cloud incluent une remorque git Claude-Session: <url>, et les corps PR incluent l'URL de la session sur sa propre ligne. Pour omettre la remorque et le lien du corps PR, définissez attribution.sessionUrl sur false.

Pour inclure le lien de session dans quelque chose d'autre qu'une validation ou une PR, comme un message Slack que Claude publie ou un fichier de rapport qu'il écrit, demandez à Claude d'exécuter la commande suivante et d'utiliser sa sortie. La commande convertit le préfixe cse_ dans la valeur de la variable d'environnement au préfixe session_ que l'URL de transcription attend :

echo "https://claude.ai/code/${CLAUDE_CODE_REMOTE_SESSION_ID/#cse_/session_}"

Exécutez des tests, démarrez des services et ajoutez des paquets

Vous n'avez pas d'accès shell à la VM de la session. Claude exécute chaque commande pour vous, donc formulez les tâches de cette section comme des demandes dans votre invite.

Exécutez des tests

Claude exécute les tests dans le cadre du travail sur une tâche. Demandez-le dans votre invite, comme « corriger les tests échoués dans tests/ » ou « exécuter pytest après chaque modification ». Les exécuteurs de tests qui viennent avec les chaînes d'outils pré-installées, comme pytest et cargo test, fonctionnent sans configuration supplémentaire. Un exécuteur que votre projet déclare comme dépendance, comme jest, s'installe avec vos dépendances.

Démarrez des services

PostgreSQL et Redis sont pré-installés mais ne s'exécutent pas par défaut. Demandez à Claude de démarrer celui dont vous avez besoin ; les commandes qu'il exécute sont :

service postgresql start

service redis-server start

Docker est disponible pour exécuter des services conteneurisés. Demandez à Claude d'exécuter docker compose up pour démarrer les services de votre projet. L'accès réseau pour extraire les images suit le niveau d'accès de votre environnement, et les défauts Trusted incluent Docker Hub et d'autres registres courants.

Si vos images sont grandes ou lentes à extraire, ajoutez docker compose pull ou docker compose build à votre script de configuration. Le cache d'environnement conserve les images extraites, donc chaque nouvelle session les a sur le disque. Le cache stocke seulement les fichiers, pas les processus en cours d'exécution, donc Claude démarre toujours les conteneurs chaque session.

Ajoutez des paquets

Pour ajouter des paquets qui ne sont pas pré-installés, utilisez un script de configuration. Le cache d'environnement conserve ce que le script installe, donc les paquets que vous installez là sont disponibles au démarrage de chaque session sans réinstallation à chaque fois. Vous pouvez aussi demander à Claude d'installer des paquets en milieu de session, mais ces installations ne se reportent pas à d'autres sessions.

Limites de ressources

Les sessions cloud dans les environnements hébergés par Anthropic s'exécutent avec des plafonds de ressources approximatifs qui peuvent changer au fil du temps :

• 4 vCPU
• 16 Go de RAM
• 30 Go de disque

La VM peut arrêter les tâches qui ont besoin de beaucoup plus de mémoire, comme les gros travaux de construction ou les tests gourmands en mémoire. Pour les charges de travail au-delà de ces limites, utilisez Remote Control pour exécuter Claude Code sur votre propre matériel, ou exécutez les sessions cloud dans un environnement auto-hébergé sur le calcul que votre organisation exploite.

Scripts de configuration

Un script de configuration est un script Bash qui s'exécute quand une nouvelle session cloud démarre, avant le lancement de Claude Code. Utilisez les scripts de configuration pour installer les dépendances, configurer les outils ou récupérer tout ce dont la session a besoin qui n'est pas pré-installé.

Les scripts s'exécutent en tant que root sur Ubuntu 24.04, donc apt install et la plupart des gestionnaires de paquets de langage fonctionnent.

Pour ajouter un script de configuration, ouvrez la boîte de dialogue des paramètres d'environnement et entrez votre script dans le champ Setup script.

Cet exemple installe ShellCheck, qui n'est pas pré-installé.

#!/bin/bash
apt update && apt install -y shellcheck

Exigences du script

Un script de configuration a trois contraintes à contourner :

• Quitter zéro : si le script quitte non-zéro, la session échoue à démarrer. Ajoutez || true aux commandes non critiques afin qu'une défaillance d'installation intermittente ne bloque pas la session.
• Terminer en cinq minutes : gardez le temps d'exécution total du script sous environ cinq minutes afin que le cache d'environnement puisse se construire. Exécutez les installations indépendantes en parallèle avec & et wait, et déplacez tout téléchargement unique qui ne rentre pas dans un crochet SessionStart qui le lance en arrière-plan.
• Accès réseau pour les installations : les installations de paquets doivent atteindre les registres. Le niveau Trusted par défaut couvre les registres de paquets courants incluant npm, PyPI, RubyGems et crates.io ; avec un accès réseau None, les installations échouent.

Mise en cache d'environnement

Le script de configuration s'exécute la première fois que vous démarrez une session dans un environnement. Après sa fin, Anthropic crée un instantané du système de fichiers et réutilise cet instantané comme point de départ pour les sessions ultérieures. Les nouvelles sessions commencent avec vos dépendances, outils et images Docker déjà sur le disque, et sautent l'étape du script de configuration. Cela garde le démarrage rapide même quand le script installe de grandes chaînes d'outils ou extrait des images de conteneur.

Le cache est un instantané du système de fichiers, donc il conserve ce que le script de configuration écrit sur le disque et perd tout ce qui était seulement en cours d'exécution. Les paquets que vous installez, les images Docker que vous extrayez et les fichiers que vous écrivez se reportent tous. Une base de données que le script a démarrée, une pile docker compose up, ou tout autre processus en arrière-plan ne le fait pas ; démarrez-les par session en demandant à Claude ou avec un crochet SessionStart.

Le script de configuration s'exécute à nouveau pour reconstruire le cache quand vous modifiez le script de configuration de l'environnement ou les hôtes réseau autorisés, et quand le cache atteint son expiration après environ sept jours. Reprendre une session existante ne réexécute jamais le script de configuration.

Vous n'avez pas besoin d'activer la mise en cache ou de gérer les instantanés vous-même.

Scripts de configuration vs. crochets SessionStart

Utilisez un script de configuration pour provisionner la VM elle-même : les chaînes d'outils et les outils CLI qui ne sont pas pré-installés. Utilisez un crochet SessionStart pour la configuration du projet qui devrait s'exécuter partout, cloud et local, comme npm install.

Les scripts de configuration et les crochets SessionStart s'exécutent dans un ordre fixe quand une session cloud démarre. Le tableau compare où vous les configurez, quand ils s'exécutent et où ils s'exécutent.

Si vous avez des crochets SessionStart dans votre ~/.claude/settings.json au niveau utilisateur, ne vous attendez pas à les voir dans le cloud : les paramètres au niveau utilisateur restent sur votre machine. Quels autres crochets s'exécutent dépend de l'endroit où la session s'exécute :

• Environnement hébergé par Anthropic : Claude Code exécute les crochets du dépôt et de vos paramètres gérés par le serveur de l'organisation.
• Environnement auto-hébergé : Claude Code exécute également les crochets que l'opérateur a ensemencés à partir de ~/.claude/ de l'hôte d'exécuteur, et les crochets dans le fichier de paramètres gérés de l'image d'exécuteur quand ce fichier est l'une des sources gérées que Claude Code applique.

Installez les dépendances avec un crochet SessionStart

Pour installer les dépendances seulement dans les sessions cloud, associez un crochet SessionStart avec un script qui vérifie où il s'exécute.

Tout d'abord, ajoutez un crochet SessionStart au .claude/settings.json de votre dépôt. Cette configuration dit à Claude Code d'exécuter scripts/install_pkgs.sh à partir de votre dépôt chaque fois qu'une session démarre ou reprend :

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "startup|resume",
        "hooks": [
          {
            "type": "command",
            "command": "bash \"$CLAUDE_PROJECT_DIR\"/scripts/install_pkgs.sh"
          }
        ]
      }
    ]
  }
}

Le matcher limite le crochet aux événements startup et resume, et $CLAUDE_PROJECT_DIR se résout à la racine du dépôt, donc le crochet trouve le script quel que soit le répertoire de travail de la session.

Ensuite, créez le script sur scripts/install_pkgs.sh. Il quitte immédiatement en dehors du cloud, puis installe vos dépendances :

#!/bin/bash

if [ "$CLAUDE_CODE_REMOTE" != "true" ]; then
  exit 0
fi

npm install
pip install -r requirements.txt
exit 0

La vérification CLAUDE_CODE_REMOTE est ce qui limite l'installation aux sessions cloud : la VM de la session porte cette variable comme true, elle n'est jamais true localement, donc sur votre ordinateur portable le script quitte avant d'installer quoi que ce soit.

Ensemble, les deux fichiers donnent à chaque session cloud un npm install et pip install frais au démarrage tout en laissant les sessions locales intactes.

Limitations dans les sessions cloud

Les crochets SessionStart se comportent de la même manière dans le cloud qu'en local, avec ces mises en garde :

• Un dépôt par session : une session avec plusieurs dépôts ne charge pas les crochets du .claude/settings.json d'aucun dépôt, donc un crochet SessionStart que vous définissez là ne s'exécute pas. Installez les dépendances pour ces sessions avec un script de configuration à la place.
• Pas de limitation au cloud uniquement : les crochets s'exécutent dans les sessions locales et cloud. Pour ignorer l'exécution locale, quittez tôt sauf si la variable d'environnement CLAUDE_CODE_REMOTE est true, de la même manière que le script d'installation de dépendances le fait.
• Nécessite un accès réseau : les commandes d'installation doivent atteindre les registres de paquets. Si votre environnement utilise un accès réseau None, ces crochets échouent. La liste d'autorisation par défaut sous Trusted couvre npm, PyPI, RubyGems et crates.io.
• Compatibilité proxy : dans les environnements hébergés par Anthropic, tout le trafic sortant passe par un proxy de sécurité, et certains gestionnaires de paquets ne fonctionnent pas correctement avec lui ; Bun est un exemple connu. Dans un environnement auto-hébergé, le trafic sortant va via votre propre limite réseau à la place.
• Ajoute une latence de démarrage : les crochets s'exécutent chaque fois qu'une session démarre ou reprend, contrairement aux scripts de configuration qui bénéficient de la mise en cache d'environnement. Gardez les scripts d'installation rapides en vérifiant si les dépendances sont déjà présentes avant de réinstaller.

Pour personnaliser l'image de base, utilisez un script de configuration pour installer ce dont vous avez besoin en haut de l'image fournie, ou exécutez votre propre image en tant que conteneur à côté de Claude avec docker compose. Remplacer l'image de base entièrement n'est pas encore supporté.

Domaines autorisés par défaut

Avec un accès réseau Trusted, les sessions peuvent atteindre les domaines suivants par défaut. Les domaines marqués avec * indiquent une correspondance de sous-domaine générique, donc *.gcr.io autorise n'importe quel sous-domaine de gcr.io.

Ressources connexes

• Référence des sessions cloud : démarrez, gérez et partagez les sessions cloud
• Démarrage rapide des sessions cloud : connectez GitHub et démarrez votre première session cloud
• Claude Tag : les sessions que Claude démarre à partir de Slack s'exécutent dans les mêmes environnements
• Routines : les exécutions programmées utilisent les mêmes environnements et niveaux d'accès réseau
• Remote Control : exécutez les sessions sur le réseau et les fichiers de votre propre machine à la place
• Environnements auto-hébergés : exécutez les sessions cloud sur l'infrastructure propre de votre organisation
• Crochets SessionStart : configuration validée dans le dépôt qui s'exécute dans les sessions locales et cloud
• Paramètres gérés par le serveur : politique organisationnelle qui atteint les sessions cloud