Exécuter Claude Code en sécurité sur un serveur

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

Pour exécuter Claude Code en sécurité sur un serveur, gardez ses demandes de permission activées, lancez-le sous un utilisateur dédié sans privilèges, et donnez aux exécutions sans surveillance une vraie limite plutôt que de la confiance : le sandbox intégré, un conteneur, ou un VPS jetable (serveur privé virtuel) qui ne contient rien qui compte pour vous. Le drapeau --dangerously-skip-permissions supprime l'étape d'approbation entre le modèle et votre shell. Ce compromis peut être raisonnable pour du travail sans surveillance, mais seulement à l'intérieur d'une limite qui restreint ce qu'une seule mauvaise commande peut atteindre. Ce guide explique ce que le drapeau change réellement, et comment construire cette limite par paliers d'isolation croissante.

Ce que Claude Code peut faire sur votre machine

Claude Code est un agent de codage qui tourne dans votre terminal. Il lit des fichiers, écrit des fichiers, et lance des commandes shell sous l'utilisateur qui l'a démarré. C'est là tout l'intérêt de l'outil : il peut cloner un dépôt, modifier du code, lancer les tests, lire l'échec, et corriger le code en boucle, sans que vous tapiez chaque commande. Si vous ne l'avez pas encore installé sur un serveur, exécuter Claude Code sur un VPS avec tmux couvre l'installation et la gestion des sessions. Cette page traite du pouvoir que vous lui confiez une fois qu'il est en place.

Le risque, c'est la même phrase lue une deuxième fois. Un processus qui lance des commandes shell sous votre utilisateur peut faire tout ce que votre utilisateur peut faire. Il peut lire ~/.ssh/id_ed25519, ~/.aws/credentials, et chaque fichier .env que votre utilisateur peut ouvrir. Il peut lancer curl et envoyer des données vers n'importe quel hôte que le serveur peut joindre. Il peut lancer git push --force. L'agent n'a aucun motif propre. Le danger, c'est qu'une tâche tourne mal, ou que du texte lu pendant le travail contienne des instructions écrites par quelqu'un d'autre : une page web qu'il a récupérée, ou un commentaire dans un ticket qu'on lui a demandé de corriger. Ce second cas s'appelle l'injection de prompt (prompt injection), et c'est pourquoi « le modèle est en général raisonnable » n'est pas un plan de sécurité. Vous prévoyez pour la mauvaise exécution, pas pour la moyenne.

Le système de permissions en mots simples

Par défaut, Claude Code demande avant d'agir. La lecture des fichiers à l'intérieur du projet se fait en silence, mais modifier un fichier ou lancer une commande shell vous montre d'abord la modification ou la commande exacte et attend un oui. Vous pouvez approuver une seule action, ou approuver ce type d'action pour le reste de la session. Ces approbations sont limitées à la session : quittez le CLI, et la session suivante redémarre prudente. Pour les règles que vous voulez conserver, le fichier de configuration contient des listes persistantes allow, ask et deny. Par exemple : autoriser git status, demander pour git push, refuser la lecture de .env. Les règles deny l'emportent toujours.

Cette conception suppose qu'un humain surveille le terminal, et sur un ordinateur portable c'est vrai. Sur un serveur, l'intérêt est souvent que personne ne surveille. Vous lancez une longue tâche dans tmux et allez vous coucher, et un agent qui s'arrête pour poser une question à 2 h du matin n'avance plus jusqu'au lendemain. C'est la raison honnête pour laquelle les gens recourent au drapeau de contournement sur les serveurs, et le problème qu'il résout est réel. Le reste de ce guide vise à le résoudre sans renoncer à toute protection.

Ce que change --dangerously-skip-permissions

claude --dangerously-skip-permissions désactive l'étape d'approbation. Les modifications se font sans demande. Les commandes shell s'exécutent sans demande. Les vérifications de chemins protégés qui gardent normalement les emplacements sensibles sont elles aussi ignorées. Vos règles deny explicites s'appliquent toujours, et quelques actions extrêmes s'arrêtent encore pour demander, mais le résumé pratique est simple : tout ce que le modèle décide de lancer, se lance.

Deux faits à propos du drapeau comptent sur un serveur. D'abord, il est bloqué quand Claude Code tourne en root ou sous sudo sur Linux et macOS, car root sans aucune demande peut modifier n'importe quel fichier ou service de la machine. L'agent a de toute façon besoin de son propre compte sans privilèges, et le drapeau l'impose. Ensuite, le drapeau ne change en rien le comportement du modèle. Il retire l'humain de la boucle et ne change rien d'autre, si bien que chaque erreur qu'une demande aurait interceptée s'exécute désormais.

Voici donc le calcul honnête. Si vous sautez les permissions, la question de sécurité passe de « l'agent va-t-il faire quelque chose de mauvais » à « combien de dégâts une seule mauvaise action peut-elle causer ». Vous cessez d'essayer de contrôler chaque décision et commencez à contrôler l'étendue des dégâts. Le confinement est la réponse, et il vient par paliers.

Le sandbox intégré de Claude Code

Avant les paliers, sachez que Claude Code livre désormais un sandbox au niveau du système d'exploitation pour les commandes qu'il lance, et il supprime la plupart des raisons pour lesquelles les gens recouraient au drapeau de contournement. Sur Linux, il utilise bubblewrap pour l'isolation du système de fichiers, plus socat pour router le trafic réseau à travers un proxy. À l'intérieur du sandbox, une commande ne peut écrire que dans le répertoire du projet et dans un répertoire temporaire de session, et elle ne peut atteindre le réseau qu'à travers un proxy qui vérifie chaque domaine dans une liste d'autorisation. La première fois qu'une commande veut un nouveau domaine, Claude Code vous demande.

Activez-le avec la commande /sandbox à l'intérieur d'une session. Sur Ubuntu et Debian, installez d'abord les deux paquets dont il a besoin :

sudo apt install bubblewrap socat

Sur Ubuntu 24.04 et versions ultérieures, la politique AppArmor par défaut empêche bubblewrap de créer les espaces de noms utilisateur (user namespaces) dont il a besoin. Le panneau du sandbox vous indique quand quelque chose manque, et la documentation sur le sandboxing de Claude Code contient le court profil AppArmor qui corrige cela.

Le sandbox a un mode d'autorisation automatique : les commandes en sandbox s'exécutent sans aucune demande, car la limite imposée fait désormais le travail que faisait la demande. Les commandes qui ne peuvent pas tourner dans le sandbox retombent sur le flux de permissions normal, si bien que les actions vraiment inhabituelles demandent encore. Pour la plupart des flux de travail sur serveur, c'est le remplacement correct du drapeau de contournement, car vous obtenez bien moins de questions avec une limite imposée par le système d'exploitation qu'avec aucune limite.

Soyez honnête sur ses limites. Par défaut, une commande en sandbox peut toujours lire la plus grande partie du système de fichiers, y compris les fichiers d'identifiants, à moins que vous ne refusiez ces chemins ; le réglage sandbox.credentials existe exactement pour cela. Le proxy réseau vérifie les noms de domaine et n'inspecte pas le trafic lui-même, si bien qu'une autorisation large comme github.com laisse encore la place pour faire sortir des données. Docker ne fonctionne pas à l'intérieur. Le sandbox relève beaucoup le plancher. Ce n'est pas une limite d'isolation complète, et c'est pourquoi les paliers ci-dessous comptent toujours.

L'échelle du confinement

Trois paliers, par ordre croissant d'isolation. Choisissez le plus bas qui correspond à ce qui vit aussi sur la machine.

Palier 1 : un utilisateur dédié sans privilèges. L'agent obtient son propre compte, son propre répertoire personnel, son propre répertoire de projet, et pas de sudo :

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

La limite du compte tient l'agent à l'écart de vos fichiers : vos clés SSH et tout autre projet sur la machine. Elle rend aussi le drapeau de contournement utilisable tout court, puisque le drapeau refuse de tourner en root. C'est le même principe que faire tourner chaque service sous un utilisateur sans privilèges, appliqué à un agent. Ce que le palier 1 ne borne pas : le réseau, et tout ce qui, sur la machine, est lisible par tous.

Palier 2 : un conteneur. Anthropic publie un devcontainer de référence qui exécute Claude Code sous un utilisateur non-root, avec des règles de pare-feu qui limitent les hôtes que l'agent peut joindre, et un conteneur que vous construisez vous-même fait le même travail. Le système de fichiers se réduit aux volumes que vous montez, et le trafic sortant se réduit à ce que les règles du conteneur autorisent. C'est le bon palier intermédiaire quand le serveur héberge d'autres services qui comptent pour vous. Sa limite : les conteneurs partagent le noyau de l'hôte, et un seul montage négligent défait la limite ; donnez au conteneur /var/run/docker.sock et il peut atteindre tout l'hôte.

Palier 3 : un VPS dédié. Le palier le plus fort est le plus brutal : donnez à l'agent une machine entière qui ne contient rien qui compte pour vous. Un petit VPS coûte quelques dollars par mois. Configurez-le avec le runbook des dix premières minutes sur un nouveau VPS, prenez un instantané de l'état propre, et laissez l'agent travailler. Rien d'autre n'y vit. Aucune clé SSH personnelle, seulement une clé de déploiement limitée à ce seul dépôt. Aucun identifiant cloud, aucune donnée de production. Quand une exécution tourne mal, ou quand vous voulez simplement repartir de zéro, restaurez l'instantané ou détruisez et reconstruisez la machine en quelques minutes. L'étendue des dégâts, c'est le loyer. C'est la configuration où --dangerously-skip-permissions cesse d'être effrayant, car le pire résultat réaliste est un serveur reconstruit et un jeton révoqué.

Les paliers se cumulent. Un agent en sandbox, tournant sous un utilisateur sans privilèges, sur un VPS jetable, coûte presque rien de plus et rend les histoires d'échec ennuyeuses. L'ennui est le but.

Protégez les identifiants

La règle qui paie pour tout le reste : l'utilisateur de l'agent ne doit pas pouvoir lire des secrets qui appartiennent à autre chose.

Donnez la clé d'API à l'agent et à rien d'autre. Mettez-la dans un fichier appartenant à l'utilisateur de l'agent avec les droits 600, et 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

Puis fermez l'autre direction. Sur Debian et Ubuntu, les répertoires personnels sont souvent créés lisibles par chaque utilisateur de la machine, alors resserrez 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 clé de déploiement propre à un dépôt, fait qu'un identifiant fuité perd un projet et non tout votre compte. Si vous utilisez le sandbox, ajoutez ses réglages d'identifiants pour que ~/.ssh et ~/.aws soient refusés même en lecture. Et gardez les identifiants de production entièrement hors de la machine, car un agent ne peut pas faire fuiter un secret qui n'a jamais été là.

Git est le filet de sécurité

Chaque changement que l'agent fait doit pouvoir être relu et annulé, et git vous donne les deux gratuitement si l'agent travaille sur une branche :

git switch -c agent/refactor-auth

Relisez l'exécution ensuite avec git diff main...agent/refactor-auth, fusionnez ce qui est bon, et supprimez la branche si l'exécution n'a rien donné. Protégez la branche main du côté de la forge, pour que le jeton de l'agent ne puisse pas y pousser ni forcer un push où que ce soit. L'historique des commits fait aussi office de journal d'audit de ce qui s'est passé pendant votre sommeil, ce qui vaut plus que n'importe quelle quantité de défilement du terminal.

Le réseau fait partie de l'étendue des dégâts

Un agent peut lancer curl. Cette phrase, c'est tout le problème du trafic sortant : tout ce que l'agent peut lire, il peut aussi l'envoyer quelque part, et un agent victime d'injection de prompt pourrait le faire. Un simple utilisateur sans privilèges ne borne pas cela du tout, car n'importe quel utilisateur peut joindre tout ce que le serveur peut joindre. Le sandbox le borne par domaine à travers son proxy. Un conteneur peut le borner avec ses propres règles de pare-feu. Un VPS dédié borne ce qu'il y a à faire fuiter au départ, ce qui est la réponse la plus robuste des trois.

N'essayez pas de résoudre le trafic sortant avec ufw seul. ufw autorise tout le trafic sortant par défaut, et écrire des règles sortantes qui permettent encore apt, npm, git et l'API Claude est un travail délicat qui casse en silence. Choisissez plutôt la limite au niveau du sandbox, du conteneur ou de la machine, où une liste d'autorisation de domaines ou une machine nue fait le même travail proprement.

Si vous construisez votre propre agent sur l'API plutôt que d'exécuter Claude Code, le même raisonnement s'applique tel quel. Construire un agent IA avec Claude sur un VPS couvre ce chemin, et son agent mérite le même utilisateur dédié, les mêmes jetons à portée limitée, et la même machine jetable.

Durcissez d'abord la machine

Quel que soit le palier que vous choisissez, la machine elle-même a encore besoin des bases avant que l'agent n'emménage : clés SSH uniquement, pas de connexion root, un pare-feu qui refuse par défaut, des mises à jour de sécurité automatiques. Générez votre liste de contrôle ici et parcourez-la une fois :

FAQ

Peut-on utiliser --dangerously-skip-permissions en sécurité sur un serveur ?

Pas à lui seul. Le drapeau supprime toute demande d'approbation, si bien que la première mauvaise commande s'exécute dès l'instant où le modèle la produit. Cela devient un compromis défendable quand l'étendue des dégâts est confinée : au minimum un utilisateur dédié sans privilèges, et pour un travail vraiment sans surveillance, un conteneur ou un VPS jetable qui ne contient qu'un projet et un seul jeton à portée limitée. Ne l'utilisez jamais sur une machine qui contient des identifiants de production ou des données que vous ne pouvez pas perdre.

Claude Code a-t-il un sandbox ?

Oui. Claude Code livre un sandbox intégré pour les commandes shell, ouvert avec la commande /sandbox. Il utilise bubblewrap sur Linux et Seatbelt sur macOS, limite les écritures au répertoire du projet, et route l'accès réseau à travers un proxy qui ne permet que les domaines approuvés. Son mode d'autorisation automatique exécute les commandes en sandbox sans demande, si bien qu'il réduit les interruptions comme le fait le drapeau de contournement, tout en gardant une limite imposée par le système d'exploitation. Ce n'est pas une limite d'isolation complète, alors associez-le à un utilisateur dédié ou à une machine dédiée pour les exécutions sans surveillance.

Pourquoi le drapeau de contournement refuse-t-il de tourner en root ?

Parce que root sans aucune demande de permission peut modifier n'importe quel fichier et n'importe quel service du système, Claude Code bloque --dangerously-skip-permissions quand il tourne en root ou sous sudo sur Linux et macOS. La solution n'est pas de combattre la vérification. Créez un utilisateur sans privilèges pour l'agent et lancez-le là ; cette limite de compte est la première et la moins chère couche de confinement.

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

Il peut lire tout ce que l'utilisateur sous lequel il tourne peut lire, et même la politique par défaut du sandbox permet la lecture des chemins d'identifiants tant que vous ne les refusez pas. Alors lancez l'agent sous son propre utilisateur, gardez votre propre répertoire personnel en droits 750 ou plus stricts, refusez les chemins d'identifiants dans les réglages du sandbox, et gardez les secrets de production entièrement hors de la machine. Un secret que la machine n'a jamais détenu ne peut être ni lu ni fuité.

Quelle est la façon la plus sûre d'exécuter Claude Code sans surveillance ?

Un VPS dédié bon marché utilisé uniquement pour le travail de l'agent : durci en dix minutes, avec un instantané propre, exécutant Claude Code sous un utilisateur sans privilèges avec le sandbox activé, un fichier en droits 600 contenant la clé d'API, une clé de déploiement propre à un dépôt, et tout le travail sur des branches que vous relisez avant de fusionner. Si une exécution tourne mal, vous révoquez un jeton et restaurez l'instantané, et rien d'autre de ce que vous possédez n'est touché.