Peut-on exécuter Claude Code sur un serveur distant ?

Oui. Installez-le sur le serveur avec npm, connectez-vous une fois et lancez-le dans tmux via SSH. La session continue après votre déconnexion, et vous vous y rattachez plus tard depuis n’importe quel ordinateur.

Comment se connecter à Claude Code sur un serveur sans navigateur ?

Lancez claude sur le serveur et ouvrez le lien de connexion sur votre propre ordinateur. Si le navigateur ne peut pas joindre le serveur, collez dans le terminal le code qu’il affiche. Pour les machines sans surveillance, claude setup-token crée un jeton de longue durée à définir dans CLAUDE_CODE_OAUTH_TOKEN.

Est-il sûr d’exécuter un agent de code sur un VPS ?

Cela peut l’être, si le serveur ne contient que ce dont l’agent a besoin. Utilisez un utilisateur distinct, gardez les secrets de production hors de la machine, fermez les ports entrants inutiles et traitez des fichiers d’identifiants comme ~/.claude/.credentials.json et ~/.codex/auth.json comme des mots de passe.

Qu’est-ce que AgentVera Runner ?

Runner est un petit service que vous installez sur votre propre serveur Linux ou macOS. Il exécute Claude Code, Codex, Gemini CLI, opencode et de simples terminaux dans de vrais terminaux qui continuent après votre déconnexion. Il se connecte uniquement en sortant, donc aucun port n’est ouvert. Il est inclus dans les forfaits Pro et Team.

AgentVera peut-il exécuter un agent sur mon serveur sans Runner ?

Oui. Dans la boîte de dialogue de l’agent, réglez « Runs on » sur un serveur SSH enregistré et choisissez un dossier sur le serveur. L’agent utilise la connexion CLI propre au serveur. Si tmux y est installé, la session survit à une connexion coupée.

Exécuter Claude Code sur un serveur distant : guide

Pour exécuter Claude Code sur un serveur distant, installez-le sur le serveur, connectez-vous une fois et lancez-le dans une session de terminal qui survit à votre déconnexion, en général tmux via SSH. C’est toute l’idée. Le reste consiste à choisir où vit le serveur, comment l’agent se connecte sans navigateur, et jusqu’où l’agent peut atteindre votre environnement depuis là.

Cet article explique pourquoi on déplace des agents vers un VPS, compare les configurations courantes, couvre la connexion sur une machine sans interface et la sécurité de base, puis montre comment AgentVera gère les agents distants avec Runner, les agents SSH et Docker.

Pourquoi exécuter un agent de code sur un serveur distant

Un portable est un mauvais foyer pour de longues exécutions d’agents. Il se met en veille, perd le Wi-Fi, et vous fermez le capot pour rentrer chez vous. Un serveur, non.

Raisons courantes de sortir les agents de votre machine :

Tâches longues. Une migration, un gros refactoring ou une suite de tests d’une heure ne devraient pas s’arrêter parce que votre portable s’est endormi.
Le code y vit déjà. Certains projets ne se compilent que sous Linux, demandent un GPU ou une base de données qui n’existe que sur ce réseau.
Isolation. Un agent sur une VM jetable ne peut toucher ni vos fichiers personnels, ni vos clés SSH, ni vos sessions de navigateur.
Accès de partout. Vous lancez une tâche à votre bureau et la suivez depuis un autre ordinateur ou votre téléphone.
Plusieurs agents à la fois. Un serveur avec plus de cœurs et de mémoire exécute plus d’agents en parallèle qu’un portable.

Le compromis, c’est la configuration et la responsabilité. Un serveur que vous contrôlez est un serveur que vous devez sécuriser.

Les options en un coup d’œil

Configuration	Survit à la déconnexion	Isolation	Effort	Idéal pour
SSH + tmux sur un VPS	Oui	Machine séparée	Faible	La plupart des gens, un ou deux projets
Dev container (local ou distant)	Tant que le conteneur tourne	Conteneur	Moyen	Environnements reproductibles, équipes
VM cloud par tâche	Oui	VM complète	Moyen à élevé	Environnements jetables, travail risqué
Agent dans un conteneur sur votre machine	Non, s’arrête avec l’agent	Conteneur	Faible	Isolation sans serveur

SSH et tmux

C’est la configuration la plus simple, et elle marche pour n’importe quel agent CLI. Sur le serveur :

npm install -g @anthropic-ai/claude-code
tmux new -s agent
cd ~/projects/my-app
claude

Détachez-vous avec Ctrl-b d et fermez SSH. L’agent continue de travailler. Plus tard, reconnectez-vous en ssh et lancez tmux attach -t agent. Si vous préférez screen ou zellij, l’idée est la même : la session appartient au serveur, pas à votre connexion SSH.

Ce que vous perdez : pas d’arborescence de fichiers, pas de vue des diffs, et passer d’un agent à l’autre revient à jongler avec les fenêtres tmux.

Dev containers

Un dev container décrit l’environnement dans un fichier (devcontainer.json plus un Dockerfile), si bien que chaque machine obtient les mêmes outils. Vous pouvez l’exécuter en local ou sur un hôte Docker distant. L’agent tourne dans le conteneur et ne voit que ce que vous y montez.

Le hic, c’est que la connexion de l’agent doit aussi exister dans le conteneur, et qu’un conteneur reconstruit perd tout ce que vous n’avez pas rendu persistant.

VM cloud

Une VM neuve par tâche donne la meilleure isolation : si l’agent saccage quelque chose, vous supprimez la machine. Cela coûte plus de configuration, et il faut un moyen de faire entrer le code et sortir le résultat, en général une branche git que l’agent pousse.

Se connecter sur une machine sans interface

Les agents de code se connectent normalement par un navigateur. Un serveur n’en a pas, il vous faut donc l’une de ces voies.

Claude Code

Navigateur sur votre ordinateur. Lancez claude sur le serveur. Il affiche un lien de connexion ; ouvrez-le sur votre propre machine. Si le navigateur ne peut pas joindre le rappel local du serveur, Claude Code affiche un code à coller à l’invite « Paste code here if prompted » dans le terminal.
Jeton de longue durée. claude setup-token crée un jeton OAuth d’un an pour un abonnement Pro, Max, Team ou Enterprise. Il n’est enregistré nulle part pour vous : définissez-le sur le serveur dans CLAUDE_CODE_OAUTH_TOKEN. Ce jeton ne couvre que les requêtes au modèle.
Clé d’API. Définissez ANTHROPIC_API_KEY si vous payez à l’usage via l’API.

Sous Linux, Claude Code stocke ses identifiants dans ~/.claude/.credentials.json avec le mode de fichier 0600. Sous macOS, ils vont dans le Trousseau, et via SSH il se rabat sur ce fichier si le Trousseau est verrouillé.

Codex

Code d’appareil. codex login --device-auth vous donne un code à saisir dans un navigateur ailleurs. C’est en bêta et il faut l’activer dans vos réglages de sécurité ChatGPT (ou par l’administrateur de votre espace de travail).
Clé d’API. printenv OPENAI_API_KEY | codex login --with-api-key.
Solutions de repli. Copiez ~/.codex/auth.json depuis une machine où vous êtes connecté, ou redirigez le port de connexion avec ssh -L 1455:localhost:1455 et connectez-vous normalement.

Quelle que soit la voie choisie, un fichier d’identifiants sur un serveur est aussi sensible qu’un mot de passe. Quiconque peut le lire peut utiliser votre abonnement.

Sécurité sur le serveur

Un agent sur un serveur exécute des commandes avec les droits de l’utilisateur sous lequel il tourne. Prévoyez-le.

Utilisez un utilisateur distinct. N’exécutez pas d’agents en root. Un utilisateur dédié avec son propre dossier personnel limite ce qu’une mauvaise commande peut atteindre.
Gardez les secrets de production hors de la machine. Si l’agent n’a pas besoin du mot de passe de la base de production, il ne doit pas figurer dans un fichier .env sur ce serveur.
Fermez les ports entrants. SSH par clés uniquement, pas de connexion par mot de passe, et aucun serveur de développement exposé que vous auriez oublié.
Travaillez sur des branches. Laissez l’agent pousser vers une branche, pas vers main. Les worktrees Git permettent à plusieurs agents de travailler sur le même dépôt sans se marcher dessus.
Surveillez les jetons de longue durée. Un jeton d’un an sur un serveur partagé est un risque d’un an. Renouvelez-le si la machine est partagée ou retirée.
Attendez-vous à l’expiration des connexions. Pour les exécutions sans surveillance, vérifiez que la session est toujours connectée avant de la laisser seule pour la nuit.

Comment AgentVera exécute des agents sur un serveur

AgentVera est une application de bureau qui exécute des CLI d’agents de code côte à côte dans de vrais terminaux avec vos propres connexions. Elle offre trois moyens de sortir des agents de votre machine.

Runner : votre propre serveur, ouvert de partout

Runner est un petit service que vous installez sur votre propre serveur Linux ou macOS, ou sur un Mac. Il exécute Claude Code, Codex, Gemini CLI, opencode et de simples sessions de terminal dans de vrais terminaux. Les sessions continuent quand vous vous déconnectez, et vous vous reconnectez depuis le navigateur ou l’application de bureau.

La configuration en bref :

Ouvrez app.agentvera.dev/runners et ajoutez un runner. Vous obtenez un code d’appairage de 8 caractères, valable 10 minutes.
Sur le serveur, lancez la commande d’installation avec ce code :

curl -fsSL https://app.agentvera.dev/runner/install.sh | sh -s -- --pair KOD

Installez la CLI sur le serveur et connectez-vous, par exemple npm install -g @anthropic-ai/claude-code puis claude login.

Runner demande Node.js 20 ou plus récent et curl ou wget. Sous Linux, il installe un service utilisateur systemd ; lancez sudo loginctl enable-linger $USER une fois pour qu’il continue à tourner quand vous vous déconnectez. Pour garder les agents dans certains dossiers, lancez agentvera-runner roots ~/projects. Sans roots, les agents travaillent dans votre dossier personnel.

Côté sécurité, Runner n’établit qu’une connexion sortante vers app.agentvera.dev sur le port 443 : vous n’ouvrez aucun port sur le serveur. Le trafic est relayé en TLS, et le serveur AgentVera ne l’interprète, ne le journalise ni ne le stocke. Votre code reste sur votre serveur, et seuls les membres actifs de votre organisation peuvent se connecter. La page Runner affiche aussi le CPU, la mémoire et le disque du serveur.

Runner est inclus dans les forfaits Pro et Team.

Agents via SSH : aucun service en plus

Si vous avez déjà un serveur dans la liste SSH d’AgentVera, vous n’avez pas besoin de Runner. Dans la boîte de dialogue de nouvel agent, réglez Runs on sur ce serveur enregistré au lieu de This computer, et choisissez le Folder on the server. L’agent s’exécute alors sur le serveur avec la connexion CLI propre au serveur. Comme l’indique la boîte de dialogue, la CLI doit être installée et connectée sur le serveur, ou vous pouvez vous connecter depuis le terminal de l’agent au premier lancement. Vos comptes locaux, MCP et réglages de navigateur ne sont pas utilisés sur le serveur.

Si tmux est installé sur le serveur, AgentVera lance l’agent dans une session tmux. Cette session survit à la connexion SSH, et la connexion suivante, depuis n’importe quel ordinateur, s’y rattache à nouveau. Quitter l’application ne l’arrête pas ; arrêter ou fermer l’agent, si.

La fonction SSH elle-même est gratuite : serveurs enregistrés, coffre chiffré pour les identifiants, SFTP et ProxyJump. Les détails sont sur la page SSH et SFTP.

Agents dans un conteneur Docker : l’isolation sans serveur

Parfois il ne vous faut pas un serveur, mais un mur. Pour un agent Claude Code ou Codex local, activez Run in a Docker container dans la boîte de dialogue de l’agent. L’agent ne voit que le dossier du projet ; les autres fichiers, programmes et clés SSH de votre ordinateur lui restent fermés. Vous pouvez définir des limites de CPU et de mémoire.

AgentVera construit sa propre image (Node 22, git, ripgrep, Claude Code et Codex) à la première utilisation, ou vous pouvez utiliser votre propre image tant qu’elle contient la commande claude ou codex. Le conteneur est supprimé quand l’agent s’arrête. Il demande Docker Desktop, Colima ou OrbStack. C’est gratuit ; voir agents dans Docker.

Lequel choisir

Vous voulez	Utilisez
Des agents qui tournent des heures sur votre serveur, ouverts depuis le navigateur	Runner (Pro et Team)
Un agent sur un serveur que vous joignez déjà par SSH	Runs on → serveur SSH enregistré
L’isolation sur votre propre machine	Run in a Docker container
Un coup d’œil rapide à un agent en cours depuis votre téléphone	L’application mobile ou Telegram

Erreurs courantes

Lancer l’agent directement dans la session SSH et le perdre quand la connexion tombe.
Exécuter l’agent en root « juste pour l’instant ».
Copier sur le serveur un .env entier avec des clés de production.
Laisser un jeton de longue durée sur une machine partagée et l’oublier.
Laisser plusieurs agents travailler dans le même dossier au lieu de branches ou de worktrees séparés.

Liste de vérification

La CLI est installée et connectée sur le serveur.
L’agent s’exécute dans tmux, Runner ou une autre session qui survit à une déconnexion.
Il tourne sous un utilisateur non root, limité aux dossiers du projet.
Aucun secret de production ne se trouve sur le serveur, sauf si la tâche l’exige.
Les ports entrants sont fermés, sauf SSH par clés.
Chaque agent travaille sur sa propre branche ou son propre worktree.

Pour conclure

Exécuter Claude Code sur un serveur distant se résume à trois choses : une session qui survit à votre connexion, une connexion qui marche sans navigateur, et un serveur qui ne contient que ce dont l’agent a besoin. SSH et tmux vous y mènent en cinq minutes. Si vous voulez lancer des agents de n’importe où, voir leurs fichiers et leurs diffs, et en garder plusieurs actifs à la fois, Runner et les agents SSH d’AgentVera font le même travail avec moins de jonglage.

Pour aller plus loin :

Pour essayer AgentVera, commencez par la page d’accueil.