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.

Le système de permissions en termes simples

En mode Manuel, Claude Code demande votre confirmation avant d’agir. La lecture des fichiers du projet se fait sans intervention, 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 réponse. Vous pouvez autoriser une seule action ou lui indiquer de ne plus poser la question. La deuxième option reste valable jusqu’à la fin de la session pour les modifications de fichiers. Pour une commande shell, elle est enregistrée définitivement pour ce dépôt et cette commande. Ainsi, un simple oui donné sur un serveur reste valable après la fin de la session. Pour les règles que vous souhaitez conserver volontairement, 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 les lectures de .env. Les règles de refus sont toujours prioritaires. Ce fonctionnement de base a également évolué. Le mode Automatique, dans lequel un classifier examine les actions à votre place, est devenu le mode par défaut des nouvelles sessions des offres Pro, Max et Team le 14 août 2026. Depuis Claude Code v2.1.283, il s’agit aussi du mode de démarrage intégré des sessions interactives dans le terminal et VS Code, quelle que soit l’offre, sauf si vous avez défini un mode par défaut. Il est donc utile de savoir ce que permet réellement chaque mode de permission avant de choisir celui qu’un serveur que vous ne pouvez pas surveiller doit utiliser.

Cette conception suppose qu’une personne surveille le terminal. C’est généralement le cas sur un laptop. Sur un serveur, personne ne regarde souvent le terminal. Vous démarrez une tâche longue dans tmux, puis vous allez vous coucher. Si un agent s’arrête pour poser une question à 2 heures du matin, il ne progresse plus avant le matin. Cette pause coûte du temps et de l’argent, car une session Claude Code inactive perd son prompt cache en mémoire et le tour suivant doit le reconstruire, ce qui est facturé. C’est la vraie raison pour laquelle les utilisateurs activent le flag skip sur les serveurs. Le problème qu’il résout 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.

La sandbox intégrée de Claude Code

Avant de passer aux niveaux, sachez que Claude Code intègre désormais une sandbox au niveau du système d’exploitation pour les commandes qu’il exécute. Elle supprime la plupart des raisons qui poussaient à utiliser le flag skip. Sous Linux, elle utilise bubblewrap pour isoler le système de fichiers, ainsi que socat pour faire passer le trafic réseau par un proxy. Dans la 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. La première fois qu’une commande veut accéder à un nouveau domaine, Claude Code vous le demande. En mode auto, le classifieur examine plutôt le nouvel hôte.

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

sudo apt install bubblewrap socat

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

La sandbox propose un mode d’auto-allow : les commandes exécutées dans la sandbox s’exécutent sans prompt, car la boundary appliquée assure désormais le rôle qu’assurait le prompt. Les commandes qui ne peuvent pas s’exécuter dans la sandbox repassent par le flux normal de permissions. Les actions réellement inhabituelles nécessitent 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 boundary appliquée par le système d’exploitation, au lieu de ne plus avoir aucune protection.

Soyez clair sur ses limites. Par défaut, une commande exécutée dans la sandbox peut encore lire la majeure partie du système de fichiers, notamment les fichiers contenant des credentials, sauf si vous interdisez ces chemins. Le paramètre sandbox.credentials existe précisément pour cela. Le proxy réseau vérifie les noms de domaine, mais n’inspecte pas le trafic lui-même. Une règle allow trop large, comme github.com, laisse donc encore la possibilité d’exfiltrer des données. Docker ne fonctionne pas à l’intérieur de la sandbox. La sandbox relève nettement le niveau de sécurité minimal. Elle ne constitue pas une isolation complète. C’est pourquoi les niveaux 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 : l’utilisateur de l’agent ne doit pas pouvoir lire les secrets appartenant à d’autres services.

Fournissez la clé d’API à l’agent uniquement. 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

Fermez ensuite l’autre accès. Sur les anciennes installations Debian et Ubuntu, ainsi que pour le compte créé pendant l’installation, les répertoires personnels peuvent être lisibles par tous les utilisateurs du système. Sécurisez donc le vôtre : chmod 750 /home/youruser. Vérifiez avec ls -ld /home/* et corrigez tout ce que le compte de l’agent peut lister.

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 sa configuration 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 soumettez-le à une revue distincte, 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 validée par l’agent peut être examinée et annulée. Git fournit gratuitement ces deux garanties si l’agent travaille sur une branche et valide ses modifications au fur et à mesure :

git switch -c agent/refactor-auth

Les modifications que l’agent ne valide jamais ne bénéficient d’aucune protection de ce type : un git reset --hard supprime les modifications non validées des fichiers suivis, et Git ne couvre pas du tout ce qui se trouve en dehors du dépôt. Examinez ensuite l’exécution avec git diff main...agent/refactor-auth pour voir ce qu’elle a validé, puis utilisez git status et git diff HEAD sur la branche pour repérer ce qu’elle a laissé non validé. Fusionnez ce qui est correct et supprimez la branche si l’exécution n’a rien produit. Une exécution qui a modifié trois fichiers est bien plus facile à examiner au petit-déjeuner qu’une exécution qui a réécrit la moitié du module. C’est tout l’intérêt pratique de la 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. Il a plus de valeur 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é.