Exécuter Claude Code sans risque sur un serveur

Ce que signifie exécuter Claude Code en toute sécurité sur un serveur

Pour exécuter Claude Code en toute sécurité sur un serveur, laissez les demandes d’autorisation activées, exécutez-le avec un utilisateur dédié et non privilégié, et imposez une véritable limite aux exécutions sans surveillance au lieu de faire confiance au modèle : utilisez le sandbox intégré, un conteneur ou un VPS temporaire qui ne contient aucune donnée importante. L’option --dangerously-skip-permissions supprime l’étape d’approbation entre le modèle et votre shell. Ce compromis peut être acceptable pour des tâches sans surveillance, mais uniquement dans un environnement isolé qui limite la portée d’une commande incorrecte. Ce guide explique ce que cette option modifie réellement et comment mettre en place cette limite avec des niveaux d’isolation croissants.

Ce que Claude Code peut faire sur votre serveur

Claude Code est un agent de programmation qui s’exécute dans votre terminal. Il lit et écrit des fichiers, et exécute des commandes shell avec les droits de l’utilisateur qui l’a lancé. C’est tout l’intérêt de l’outil : il peut cloner un dépôt, modifier le code, exécuter les tests, lire l’erreur, puis corriger le code en boucle, sans que vous ayez à saisir chaque commande. Si vous ne l’avez pas encore installé sur un serveur, la page exécuter Claude Code sur un VPS avec tmux décrit l’installation et la gestion de la session. Cette page décrit les droits que vous lui accordez une fois qu’il est installé.

Le risque apparaît dès que l’on relit la phrase précédente. Un processus qui exécute des commandes shell avec vos droits peut faire tout ce que vous pouvez faire. Il peut lire ~/.ssh/id_ed25519, ~/.aws/credentials et tous les fichiers .env que votre utilisateur peut ouvrir. Il peut exécuter curl et envoyer des données vers n’importe quel hôte accessible depuis le serveur. Il peut exécuter git push --force. L’agent n’a pas de volonté propre. Le danger vient d’une tâche qui se déroule mal, ou du texte lu pendant son exécution qui contient des instructions écrites par quelqu’un d’autre : une page web qu’il a récupérée ou un commentaire dans une issue qu’on lui a demandé de corriger. Ce second cas s’appelle une injection de prompt. C’est pourquoi « le modèle est généralement raisonnable » ne constitue pas une stratégie de sécurité. Les instructions peuvent également venir d’un contexte plus proche, car deux sessions Claude Code sur le même serveur peuvent s’envoyer du texte, et un message provenant d’une session sœur n’est qu’un texte supplémentaire lu par l’agent qui le reçoit. Vous devez vous préparer à une exécution problématique, et non au cas moyen.

Les permissions en termes simples

Par défaut, Claude Code demande votre autorisation avant d’agir. La lecture des fichiers du projet se fait en silence, mais la modification d’un fichier ou l’exécution d’une commande shell affiche d’abord la modification ou la commande exacte et attend votre confirmation. Vous pouvez approuver une action unique ou approuver ce type d’action pour le reste de la session. Ces autorisations sont limitées à la session : quittez la CLI, et la session suivante redémarre avec le mode prudent. Pour les règles à conserver, le fichier de configuration contient des listes persistantes d’autorisations, de demandes de confirmation et de refus. Par exemple : autoriser git status, demander une confirmation pour git push, refuser la lecture de .env. Les règles de refus sont toujours prioritaires. Ce fonctionnement de base évolue lui aussi, car le mode automatique devient le mode par défaut le 14 août 2026. Il est donc utile de savoir ce que chaque mode de permission autorise réellement avant de choisir celui qu’un serveur que vous ne pouvez pas surveiller doit utiliser.

Cette conception suppose qu’une personne surveille le terminal, ce qui est généralement le cas sur un laptop. Sur un serveur, personne ne surveille souvent le terminal. Vous lancez une tâche longue dans tmux et allez vous coucher. Si un agent s’arrête pour poser une question à 2 heures du matin, il ne progresse plus jusqu’au matin. Cette pause coûte du temps et de l’argent, car une session Claude Code inactive perd son cache de prompt prêt à l’emploi et le tour suivant doit le reconstruire. C’est la raison concrète pour laquelle les utilisateurs activent le flag skip sur les serveurs, et le problème résolu est réel. La suite de ce guide explique comment le résoudre sans supprimer toutes les protections.

Ce que modifie --dangerously-skip-permissions

claude --dangerously-skip-permissions désactive l’étape d’approbation. Les modifications sont effectuées sans confirmation. Les commandes shell sont exécutées sans confirmation. Les vérifications des chemins protégés, qui servent normalement à protéger les emplacements sensibles, sont également ignorées. Vos règles de refus explicites continuent de s’appliquer, et quelques actions particulièrement risquées demandent encore une confirmation, mais le résumé opérationnel est simple : tout ce que le modèle décide d’exécuter est exécuté.

Deux faits concernant ce flag sont importants sur un serveur. Premièrement, il est bloqué lorsque Claude Code s’exécute en tant que root ou avec sudo sous Linux et macOS, car root sans confirmation peut modifier n’importe quel fichier ou service de la machine. L’agent doit de toute façon utiliser son propre compte non privilégié, et ce flag l’impose. Deuxièmement, ce flag ne modifie en rien le comportement du modèle. Il retire l’humain de la boucle et ne change rien d’autre. Chaque erreur qu’une demande de confirmation aurait permis d’éviter est donc maintenant exécutée.

Voici donc le calcul réel. Si vous ignorez les permissions, la question de sécurité passe de « l’agent va-t-il faire quelque chose de dangereux ? » à « quelle ampleur peuvent avoir les dégâts causés par une seule mauvaise action ? ». Vous cessez d’essayer de contrôler chaque décision et commencez à limiter le rayon d’impact. Le confinement est la réponse, et il se met en place par niveaux.

Le sandbox intégré de Claude Code

Avant de passer aux paliers, sachez que Claude Code intègre désormais un sandbox au niveau du système d’exploitation pour les commandes qu’il exécute. Cela élimine la plupart des raisons qui poussaient à utiliser le flag skip. Sous Linux, il utilise bubblewrap pour isoler le système de fichiers, ainsi que socat pour faire passer le trafic réseau par un proxy. Dans le sandbox, une commande peut écrire uniquement dans le répertoire du projet et dans un répertoire temporaire de session. Elle ne peut accéder au réseau que par un proxy qui vérifie chaque domaine dans une allow list. Lorsqu’une commande demande l’accès à un nouveau domaine pour la première fois, Claude Code vous le demande.

Activez-le avec la commande /sandbox dans une session. Sur Ubuntu et Debian, installez d’abord les deux paquets nécessaires :

sudo apt install bubblewrap socat

Sur Ubuntu 24.04 et les versions ultérieures, la règle AppArmor par défaut empêche bubblewrap de créer les user namespaces dont il a besoin. Le panneau du sandbox vous indique lorsqu’un élément manque. La documentation sur le sandboxing de Claude Code contient le profil AppArmor court qui corrige ce problème.

Le sandbox dispose d’un mode d’autorisation automatique : les commandes exécutées dans le sandbox ne demandent aucune confirmation, car la limite appliquée par le système remplit désormais le rôle qui revenait auparavant à la confirmation. Les commandes qui ne peuvent pas s’exécuter dans le sandbox repassent par le flux d’autorisations normal. Les actions réellement inhabituelles demandent donc toujours une confirmation. Pour la plupart des workflows serveur, c’est le remplacement correct du flag skip : vous obtenez beaucoup moins de questions grâce à une limite imposée par le système, au lieu de n’avoir aucune limite.

Soyez conscient de ses limites. Par défaut, une commande exécutée dans le sandbox peut toujours lire la plupart des fichiers du système, notamment les fichiers contenant des credentials, sauf si vous interdisez ces chemins. Le paramètre sandbox.credentials sert précisément à cela. Le proxy réseau vérifie les noms de domaine, mais n’inspecte pas le trafic lui-même. Une autorisation large comme github.com permet donc toujours d’exfiltrer des données. Docker ne fonctionne pas à l’intérieur du sandbox. Le sandbox relève fortement le niveau de sécurité minimal. Il ne constitue pas une limite d’isolation complète. C’est pourquoi les paliers ci-dessous restent importants.

L’échelle de confinement

Trois niveaux, classés du moins au plus isolé. Choisissez le niveau le plus bas qui tient compte des autres éléments présents sur la machine.

Niveau 1 : un utilisateur dédié sans privilèges. L’agent dispose de son propre compte, de son propre répertoire personnel, de son propre répertoire de projet et d’aucun accès sudo :

sudo adduser --disabled-password --gecos "" agent

La séparation par compte empêche l’agent d’accéder à vos fichiers : vos clés SSH et tous les autres projets de la machine. Elle rend également le flag skip utilisable, car ce flag refuse de s’exécuter avec root. C’est le même principe que exécuter chaque service avec un utilisateur sans privilèges, appliqué à un agent. Ce que le niveau 1 ne limite pas : le réseau et tout ce qui est lisible par tous sur la machine.

Niveau 2 : un conteneur. Anthropic publie un devcontainer de référence qui exécute Claude Code avec un utilisateur non-root, avec des règles de firewall qui limitent les hôtes que l’agent peut joindre. Un conteneur que vous construisez vous-même remplit le même rôle. Le système de fichiers se limite aux volumes que vous montez, et le trafic sortant se limite à ce que les règles du conteneur autorisent. C’est le niveau intermédiaire adapté lorsque le serveur héberge d’autres services auxquels vous tenez. Sa limite est que les conteneurs partagent le kernel de l’hôte, et qu’un montage imprudent annule la séparation ; accordez /var/run/docker.sock au conteneur et il pourra accéder à l’ensemble de l’hôte.

Niveau 3 : un VPS dédié. Le niveau le plus fort est aussi le plus simple : donnez à l’agent une machine entière qui ne contient rien d’important pour vous. Un petit VPS coûte quelques dollars par mois. Configurez-le avec la procédure des dix premières minutes sur un nouveau VPS, créez un snapshot de l’état propre, puis laissez l’agent travailler. Rien d’autre n’y est hébergé. Aucune clé SSH personnelle, uniquement une deploy key limitée au dépôt concerné. Aucun identifiant cloud, aucune donnée de production. Lorsqu’une exécution se passe mal, ou lorsque vous voulez simplement repartir d’un état propre, restaurez le snapshot ou détruisez et recréez la machine en quelques minutes. Le rayon d’impact se limite au coût de la location. Avec cette configuration, --dangerously-skip-permissions ne fait plus peur, car le pire scénario réaliste est un serveur reconstruit et un token révoqué.

Les niveaux se combinent. Un agent sandboxé, exécuté avec un utilisateur sans privilèges sur un VPS jetable, ne coûte presque rien de plus et rend les incidents banals. C’est l’objectif.

Protéger les identifiants

La règle qui conditionne tout le reste est la suivante : l’utilisateur de l’agent ne doit pas pouvoir lire les secrets appartenant à d’autres services.

Donnez la clé d’API à l’agent, et à lui seul. Placez-la dans un fichier appartenant à l’utilisateur de l’agent, avec le mode 600, puis chargez-la au démarrage d’un shell :

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

Bloquez ensuite l’accès dans l’autre sens. Sur Debian et Ubuntu, les répertoires personnels sont souvent créés avec des droits de lecture pour tous les utilisateurs du système. Restreignez donc le vôtre : chmod 750 /home/youruser. Vérifiez le résultat avec ls -ld /home/* et corrigez tout ce que le compte de l’agent peut parcourir.

Limitez la portée de chaque jeton. Un jeton GitHub à granularité fine, limité à un seul dépôt, ou une deploy key propre à un dépôt, signifie qu’un identifiant divulgué ne compromet qu’un projet, et non l’ensemble de votre compte. Si vous utilisez la sandbox, ajoutez ses paramètres d’identifiants afin que ~/.ssh et ~/.aws soient refusés, même en lecture. Gardez également les identifiants de production entièrement hors de cette machine : un agent ne peut pas divulguer un secret qui ne s’y trouve pas. Si ces secrets sont stockés dans un gestionnaire de mots de passe auto-hébergé, installez-le sur une autre machine que celle de l’agent et faites-le vérifier séparément, car les points faibles de Vaultwarden sont le jeton d’administration et le fichier de sauvegarde, et non le coffre chiffré lui-même.

Git est le filet de sécurité

Chaque modification effectuée par l’agent doit pouvoir être relue et annulée. Git fournit ces deux garanties si l’agent travaille sur une branche :

git switch -c agent/refactor-auth

Relisez ensuite l’exécution avec git diff main...agent/refactor-auth, fusionnez ce qui est correct et supprimez la branche si l’exécution n’a rien produit d’utile. Une exécution qui a modifié trois fichiers est bien plus facile à relire au petit-déjeuner qu’une autre qui a réécrit la moitié du module. C’est l’intérêt pratique de compétence qui impose à l’agent la plus petite modification fonctionnelle. Protégez la branche principale côté forge afin que le token de l’agent ne puisse pas y pousser de modifications et ne puisse effectuer aucun force-push. L’historique des commits sert aussi de journal d’audit de ce qui s’est passé pendant votre sommeil. Cela vaut mieux que n’importe quelle quantité de défilement dans le terminal.

Le réseau fait partie du périmètre d’impact

Un agent peut exécuter curl. Cette phrase résume tout le problème des connexions sortantes : tout ce que l’agent peut lire, il peut aussi l’envoyer quelque part, et un agent manipulé par injection de prompt peut le faire. Un simple utilisateur sans privilèges ne limite pas du tout ce risque, car n’importe quel utilisateur peut atteindre tout ce que le serveur peut atteindre. La sandbox le limite par domaine grâce à son proxy. Un conteneur peut le limiter avec ses propres règles de firewall. Un VPS dédié limite d’abord la quantité de données susceptibles d’être exfiltrées, ce qui constitue la réponse la plus robuste des trois.

N’essayez pas de résoudre le problème des connexions sortantes avec ufw uniquement. ufw autorise par défaut tout le trafic sortant, et rédiger des règles sortantes qui continuent d’autoriser apt, npm, git et l’API Claude demande un travail délicat, avec des blocages qui peuvent rester silencieux. Choisissez plutôt la limite au niveau de la sandbox, du conteneur ou de la machine. Une allow list de domaines ou une machine dédiée répond au même besoin de manière claire.

Si vous développez votre propre agent avec l’API au lieu d’exécuter Claude Code, le même raisonnement s’applique. Développer un agent IA avec Claude sur un VPS décrit cette approche. Cet agent doit utiliser le même utilisateur dédié, les mêmes tokens à portée limitée et la même machine jetable.

Renforcez d’abord le serveur

Quel que soit le niveau choisi, le serveur lui-même doit disposer des protections de base avant l’installation de l’agent : clés SSH uniquement, aucune connexion root, pare-feu en refus par défaut et mises à jour de sécurité automatiques. Générez votre checklist ici, puis suivez-la une fois :

FAQ

Est-il sûr d’utiliser --dangerously-skip-permissions sur un serveur ?

Pas en soi. Ce flag supprime toutes les demandes d’autorisation. La première commande dangereuse s’exécute donc dès que le modèle la génère. Ce choix peut se justifier si le périmètre d’impact est limité : utilisez au minimum un utilisateur dédié sans privilèges et, pour les tâches réellement sans supervision, un conteneur ou un VPS jetable qui ne contient qu’un seul projet et un seul token avec une portée limitée. Ne l’utilisez jamais sur une machine qui contient des identifiants ou des données de production que vous ne pouvez pas perdre.

Claude Code dispose-t-il d’un sandbox ?

Oui. Claude Code fournit un sandbox intégré pour les commandes shell, que vous ouvrez avec la commande /sandbox. Il utilise bubblewrap sous Linux et Seatbelt sous macOS. Il limite les écritures au répertoire du projet et fait passer l’accès réseau par un proxy qui n’autorise que les domaines approuvés. Son mode d’autorisation automatique exécute les commandes dans le sandbox sans demander de confirmation. Il réduit donc les interruptions comme le flag de contournement, tout en conservant une limite imposée par le système d’exploitation. Ce n’est pas une isolation complète. Pour les exécutions sans supervision, associez-le donc à un utilisateur dédié ou à une machine dédiée.

Pourquoi le flag de contournement refuse-t-il de s’exécuter en tant que root ?

Parce que root, sans demande d’autorisation, peut modifier n’importe quel fichier et n’importe quel service du système. Claude Code bloque donc --dangerously-skip-permissions lorsqu’il s’exécute en tant que root ou avec sudo sous Linux et macOS. La solution ne consiste pas à contourner ce contrôle. Créez un utilisateur sans privilèges pour l’agent et exécutez-le avec ce compte. Cette séparation par utilisateur constitue la première couche de confinement, et la moins coûteuse.

Claude Code peut-il lire mes clés SSH et mes fichiers .env ?

Il peut lire tout ce que l’utilisateur avec lequel il s’exécute peut lire. Même la stratégie par défaut du sandbox autorise la lecture des chemins contenant des identifiants tant que vous ne l’interdisez pas. Exécutez donc l’agent avec son propre utilisateur, gardez votre répertoire personnel avec le mode 750 ou un mode plus restrictif, interdisez les chemins contenant des identifiants dans la configuration du sandbox et ne stockez jamais les secrets de production sur cette machine. Un secret que la machine n’a jamais contenu ne peut pas être lu ni divulgué.

Quelle est la méthode la plus sûre pour exécuter Claude Code sans supervision ?

Utilisez un VPS dédié peu coûteux, réservé au travail de l’agent : durcissez-le en dix minutes, créez un snapshot propre, exécutez Claude Code avec un utilisateur sans privilèges et avec le sandbox activé, stockez la clé API dans un fichier au mode 600, utilisez une deploy key par dépôt et effectuez tout le travail sur des branches que vous examinez avant la fusion. Si une exécution se passe mal, vous révoquez un seul token et restaurez le snapshot. Rien d’autre ne vous appartenant n’est alors affecté.