Skip to main content
Les environnements cloud nécessitent Claude Code sur le web, qui est en aperçu de recherche pour les utilisateurs Pro, Max et Team, et pour les utilisateurs Enterprise disposant de sièges premium ou de sièges Chat + Claude Code.
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 : Claude Code sur le web, le terminal avec claude --cloud, Claude Tag, routines, l’application mobile Claude et l’application de bureau. 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.
Les sessions Remote Control connectent les interfaces web et mobile à une session sur votre propre machine, qui utilise le réseau et les fichiers de votre machine, et non un environnement cloud. Les sessions de canal Claude Tag utilisent uniquement des environnements au niveau de l’organisation, soit des environnements partagés, soit des environnements auto-hébergés.

​
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 le web, l’application Desktop et l’application mobile, les sessions 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.
  • 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.

​
Configurez votre environnement

Créez, modifiez et archivez les environnements à partir du sélecteur d’environnement sur claude.ai/code, que vous atteignez après l’intégration web. 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

Ouvrez 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 boîte de message. Il n’y a pas de page de paramètres ou d’URL directe pour le sélecteur.
Le sélecteur d'environnement ouvert au-dessus de la boîte de message sur claude.ai/code. Le bouton cloud affichant le nom de l'environnement Default se trouve dans la ligne au-dessus de la boîte de message. Le menu ouvert liste une ligne Local avec les étiquettes Download et Desktop only, une section Cloud où l'environnement Default est sélectionné avec une coche et affiche une icône d'engrenage de paramètres au survol, une option Add cloud environment, et une section Remote Control avec les instructions de configuration.
2

Ajoutez ou modifiez 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. Quand vous modifiez un environnement cloud existant sur un plan Pro ou Max, la boîte de dialogue inclut également les identifiants API.
La boîte de dialogue New cloud environment. Un champ Name avec le texte d'espace réservé Default, un sélecteur Network access défini sur Trusted avec des liens vers la politique réseau et les niveaux d'accès, une boîte Environment variables affichant un texte d'espace réservé au format .env avec une note indiquant que les valeurs sont visibles pour quiconque utilise l'environnement, une boîte Setup script décrite comme un script Bash qui s'exécute quand une nouvelle session démarre avant le lancement de Claude Code, et les boutons Cancel et Create environment.

​
Définissez 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 citez une valeur avec une paire correspondante, les guillemets ne deviennent pas partie de la valeur. Citez une valeur qui s’étend sur plusieurs lignes ou contient un # : dans une valeur non citée, # démarre un commentaire et le reste de la ligne est supprimé. L’exemple suivant définit trois variables.
Chaque session copie les valeurs de l’environnement une fois, au démarrage, dans des variables d’environnement ordinaires que n’importe quelle commande que Claude exécute peut lire. Parce que les sessions en cours d’exécution ne relisent pas la configuration, modifier ou ajouter des variables affecte les sessions que vous démarrez après ; les sessions déjà en cours d’exécution conservent les valeurs avec lesquelles elles ont démarré. Claude Code sur le web définit également certaines variables lui-même quand il démarre une session. Pour CLAUDE_AUTOCOMPACT_PCT_OVERRIDE, la valeur que Claude Code sur le web 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 un identifiant API pour une clé que le proxy d’agent peut joindre à une requête. Les requêtes qui ne reçoivent jamais d’identifiant sont listées là.

​
Ajoutez 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 requêtes pour les hôtes que vous listez, après que chaque requête 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 de l’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 requêtes 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

​
Ajoutez 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 d’édition. Pour modifier les hôtes ou la valeur d’un identifiant, supprimez-le et ajoutez-le à nouveau.
1

Ouvrez les identifiants API de l'environnement

Ouvrez l’environnement pour modification sur claude.ai/code. Dans la boîte de dialogue Update cloud environment, trouvez API credentials sous Environment variables. Vous voyez les identifiants déjà sur l’environnement, chacun avec les hôtes auxquels il s’applique.
2

Ajoutez l'identifiant

Sélectionnez Add credential et remplissez le formulaire. Conservez le Credential type par défaut, Bearer, pour une clé API qui voyage dans un en-tête de requête, et remplissez ces champs :
  • Name : une étiquette pour l’identifiant, comme Internal billing API
  • Allowed websites : les hôtes de l’API, comme api.example.com. Un *. au début correspond à chaque sous-domaine
  • Custom headers : une ligne pour l’en-tête qui porte la clé. La ligne commence par Authorization comme Name de l’en-tête et Bearer comme son Prefix ; collez la clé elle-même comme Value. Pour un en-tête comme X-Api-Key qui prend la valeur nue, changez le nom et effacez le préfixe
Pour une API qui s’authentifie d’une autre manière, choisissez un Credential type différent. La liste est la même que celle que Claude Tag, l’intégration Slack pour les plans Team et Enterprise, propose pour les connexions.
3

Enregistrez l'identifiant

Sélectionnez Connect. L’identifiant apparaît dans la liste avec ses hôtes, enregistré sans le bouton Save changes de la boîte de dialogue. Vous ne pouvez pas voir la valeur à nouveau après l’enregistrement.
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 requête, 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 lui dit 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 requêtes reçoivent l’identifiant

Le proxy d’agent joint un identifiant à une requête quand l’hôte de la requête correspond à un que vous avez listé sur cet identifiant. Les sessions peuvent atteindre ces hôtes même quand le niveau d’accès réseau de l’environnement ne le permettrait pas autrement, sauf les hôtes que le proxy d’agent ignore. 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.

​
Requêtes qui ne reçoivent jamais l’identifiant

Le proxy d’agent ne joint jamais un identifiant que vous ajoutez à ces requêtes :
  • GitHub : le proxy GitHub authentifie les requêtes à GitHub à la place, donc vous n’avez pas besoin d’un identifiant API pour cela
  • L’API Anthropic et les registres de paquets publics : les requêtes à api.anthropic.com, registry.npmjs.org, jsr.io, npm.jsr.io, pypi.org, files.pythonhosted.org, index.crates.io et proxy.golang.org ne passent pas par le proxy d’agent
  • Requêtes de script de configuration : Claude Code se connecte au proxy d’agent quand il se lance, après que le script de configuration ait s’exécuté

​
Sélectionnez un environnement depuis le CLI

Exécutez /remote-env dans votre terminal pour choisir l’environnement par défaut pour les sessions cloud que vous créez depuis le 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 elle s’applique dans chaque projet sur votre machine jusqu’à ce que vous la changiez, sauf si la même clé est définie à une couche de paramètres de priorité 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 pour cela. /remote-env définit seulement le défaut : il ne démarre pas une session, et il ne peut pas ajouter ou modifier des environnements. Gérez-les sur claude.ai/code.

​
Archivez un environnement

Pour archiver un environnement, ouvrez-le pour modification et sélectionnez Archive. 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 à 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 n’importe quelle 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 quand votre liste en a un, et sinon dans le premier environnement de votre liste qui n’est pas un environnement bridge 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 Cloud environments de l’administration, 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 à côté de leurs environnements personnels, donc une équipe peut se standardiser sur une configuration au lieu que chaque membre la recréé. Créez, modifiez et archivez les environnements partagés à partir de la page Cloud environments dans les paramètres d’administration. Un environnement partagé s’ouvre également à partir du sélecteur d’environnement sur claude.ai/code : un propriétaire peut le modifier là. Les autres membres le voient en lecture seule. Chaque environnement partagé a un nom, un niveau d’accès réseau, des variables d’environnement au format .env, et un script de configuration. Les propriétaires choisissent l’environnement par défaut de l’organisation séparément, sur claude.ai/admin-settings/claude-code. Chaque session d’un membre dans un environnement partagé lit 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éfinissez 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 des environnements partagés, soit des 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 deux façons :

​
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 le modifier et utilisez le sélecteur Network access dans la boîte de dialogue. L’icône cloud qui ouvre le sélecteur apparaît sur les surfaces de l’application listées sous L’environnement par défaut et dans l’éditeur de routine ; les environnements personnels n’ont pas de page séparée dans les paramètres de votre compte claude.ai.
Les connecteurs MCP que vous activez sur une session ou une routine fonctionnent sans ajouter leurs hôtes aux Allowed domains, car le trafic des connecteurs transite par les serveurs d’Anthropic plutôt que par le réseau de la session. Vous configurez les connecteurs par session ou par routine ; supprimez ceux que vous n’avez pas besoin pour limiter les outils que Claude peut atteindre. Cela repose sur le même canal lié à Anthropic noté sous Sécurité et isolation.

​
Niveaux d’accès

Le champ Network access dans la boîte de dialogue d’environnement prend l’une 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 :

​
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.
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 aux hôtes des identifiants API de l’environnement, autres que les hôtes que le proxy d’agent ignore, ne passent pas par cette liste d’autorisation. Un *. au début correspond à chaque sous-domaine. 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 artefacts, vous n’avez pas besoin de *.frame.claudeusercontent.com dans la liste pour que les sessions les lisent. Quand la liste laisse cet hôte de côté, Claude Code lit le contenu des artefacts 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 artefacts publics d’une autre organisation : Claude Code les récupère directement à partir de l’hôte, donc ajoutez-le à cette liste.
  • Vous configurez le CLI local ou un exécuteur auto-hébergé : conservez l’hôte dans cette liste d’autorisation. Consultez les exigences d’accès réseau et les exigences réseau 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 appliquer aux environnements de chaque membre. Les paramètres gérés par le serveur s’appliquent toujours dans les sessions cloud, mais aucun d’entre eux n’ajoute de domaines à la liste d’autorisation réseau de l’environnement.

​
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 ; la section Configurez git couvre les options, y compris les identifiants frappés 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 jeton 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 envois : 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 demandes d’actifs de version ne peuvent atteindre 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 sert seulement un ensemble épinglé d’opérations GraphQL pour les flux de travail de demande de tirage. 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 les identifiants 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 existent uniquement 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.
Les sessions que votre organisation route vers un environnement auto-hébergé s’exécutent sur vos propres exécuteurs à la place, avec les outils que votre image d’exécuteur fournit.

​
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 slash ; 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 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. 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. Cela nécessite v2.1.179 ou ultérieur. Pour omettre la remorque et le lien du corps PR, définissez attribution.sessionUrl sur false. Le paramètre nécessite v2.1.182 ou ultérieur. 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 :

​
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 :
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é.

​
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 :

​
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 :
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 :
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 :
  • Pas de limitation au cloud uniquement : les crochets s’exécutent dans les sessions locales et cloud. Pour ignorer l’exécution locale, vérifiez la variable d’environnement CLAUDE_CODE_REMOTE comme montré ci-dessus.
  • 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.
  • api.anthropic.com
  • statsig.anthropic.com
  • docs.claude.com
  • platform.claude.com
  • code.claude.com
  • claude.ai
  • github.com
  • www.github.com
  • api.github.com
  • npm.pkg.github.com
  • raw.githubusercontent.com
  • pkg-npm.githubusercontent.com
  • objects.githubusercontent.com
  • release-assets.githubusercontent.com
  • codeload.github.com
  • avatars.githubusercontent.com
  • camo.githubusercontent.com
  • gist.github.com
  • gitlab.com
  • www.gitlab.com
  • registry.gitlab.com
  • bitbucket.org
  • www.bitbucket.org
  • api.bitbucket.org
  • registry-1.docker.io
  • auth.docker.io
  • index.docker.io
  • hub.docker.com
  • www.docker.com
  • production.cloudflare.docker.com
  • download.docker.com
  • gcr.io
  • *.gcr.io
  • ghcr.io
  • mcr.microsoft.com
  • *.data.mcr.microsoft.com
  • public.ecr.aws
  • cloud.google.com
  • accounts.google.com
  • gcloud.google.com
  • *.googleapis.com
  • storage.googleapis.com
  • compute.googleapis.com
  • container.googleapis.com
  • azure.com
  • portal.azure.com
  • microsoft.com
  • www.microsoft.com
  • *.microsoftonline.com
  • packages.microsoft.com
  • dotnet.microsoft.com
  • dot.net
  • visualstudio.com
  • dev.azure.com
  • *.amazonaws.com
  • *.api.aws
  • oracle.com
  • www.oracle.com
  • java.com
  • www.java.com
  • java.net
  • www.java.net
  • download.oracle.com
  • yum.oracle.com
  • proxy.golang.org
  • sum.golang.org
  • index.golang.org
  • golang.org
  • www.golang.org
  • goproxy.io
  • pkg.go.dev
  • maven.org
  • repo.maven.org
  • central.maven.org
  • repo1.maven.org
  • repo.maven.apache.org
  • jcenter.bintray.com
  • gradle.org
  • www.gradle.org
  • services.gradle.org
  • plugins.gradle.org
  • kotlinlang.org
  • www.kotlinlang.org
  • spring.io
  • repo.spring.io
  • dl.k8s.io (Kubernetes)
  • pkgs.k8s.io
  • k8s.io
  • www.k8s.io
  • releases.hashicorp.com (HashiCorp)
  • apt.releases.hashicorp.com
  • rpm.releases.hashicorp.com
  • archive.releases.hashicorp.com
  • hashicorp.com
  • www.hashicorp.com
  • repo.anaconda.com (Anaconda/Conda)
  • conda.anaconda.org
  • anaconda.org
  • www.anaconda.com
  • anaconda.com
  • continuum.io
  • apache.org (Apache)
  • www.apache.org
  • archive.apache.org
  • downloads.apache.org
  • eclipse.org (Eclipse)
  • www.eclipse.org
  • download.eclipse.org
  • nodejs.org (Node.js)
  • www.nodejs.org
  • developer.apple.com
  • developer.android.com
  • pkg.stainless.com
  • binaries.prisma.sh
  • statsig.com
  • www.statsig.com
  • api.statsig.com
  • sentry.io
  • *.sentry.io
  • downloads.sentry-cdn.com
  • http-intake.logs.datadoghq.com
  • browser-intake-us5-datadoghq.com
  • *.datadoghq.com
  • *.datadoghq.eu
  • api.honeycomb.io
  • sourceforge.net
  • *.sourceforge.net
  • packagecloud.io
  • *.packagecloud.io
  • fonts.googleapis.com
  • fonts.gstatic.com
  • *.modelcontextprotocol.io
  • Claude Code sur le web : démarrez, gérez et partagez les sessions cloud
  • Démarrage rapide web : 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