Faire tourner ses agents de code sur un serveur : SSH + tmux, capot fermé

Par Meffysto · mis à jour le 4 octobre 2026

Vous confiez une tâche longue à un agent, vous fermez le portable, vous prenez le train : l'agent est mort avec la session. La parade est ancienne, solide, et ne demande aucun service tiers : SSH plus tmux. Voici la recette, les quatre détails qui font la différence entre « ça survit » et « je ne retrouve rien », et quoi vérifier quand ça ne marche pas.

Pourquoi ça meurt

Un agent en ligne de commande est un processus rattaché à un terminal. Fermez le terminal, l'application ou le capot : le terminal disparaît, le processus reçoit son congé, la session est perdue, souvent au milieu d'une modification. L'agent n'y est pour rien. C'est la façon dont fonctionnent les terminaux.

La solution consiste donc à déplacer le terminal, pas l'agent. Il doit vivre sur une machine qui, elle, ne se ferme pas, et votre écran ne fait que s'y brancher. Cette machine peut être un serveur loué, un mini-PC dans un placard, ou un Mac de bureau qui reste allumé.

La recette de base

Sur une machine joignable en SSH, où l'agent est installé et connecté à votre compte :

ssh -t mon-serveur -- tmux new -A -s agent-claude claude

Trois morceaux, tous indispensables :

ssh -t force un vrai terminal côté serveur. Sans lui, les interfaces plein écran des agents s'affichent n'importe comment.
tmux new -A -s <nom> crée la session si elle n'existe pas, et s'y rattache si elle existe déjà. C'est ce petit -A qui transforme la commande en « ouvre ou reprends ».
claude est l'agent lui-même, qui tourne maintenant dans tmux, à l'abri de la fin de votre connexion.

Fermez le portable : tmux continue sur le serveur. Relancez la même commande demain, depuis un autre Mac : vous retombez dans la session en cours, avec son historique. Remplacez claude par codex, gemini ou un autre CLI, la recette ne change pas.

Détail 1 : le nom de session doit être stable

C'est l'erreur la plus fréquente. Si le nom contient l'heure, un identifiant aléatoire ou un numéro de fenêtre, -A ne rattache jamais rien : il crée une session de plus à chaque essai, et vous accumulez des agents fantômes qui consomment vos quotas sans que personne les regarde.

Un nom stable, tiré de ce que vous ouvrez, suffit. Fauconnier préfixe toutes ses sessions distantes par fauconnier- : fauconnier-claude, puis fauconnier-claude-2 si vous voulez volontairement un second agent du même CLI sur la même machine. Redemander « ouvre un agent claude sur falcon-prod » rattache la session existante au lieu d'en créer une autre.

Détail 2 : la confiance du dossier se pose sur le serveur

La plupart des agents demandent, au premier lancement dans un dossier, s'ils ont le droit d'y travailler. Cette réponse est stockée sur la machine où tourne l'agent, donc sur le serveur, pas sur votre Mac. Si vous ne préparez rien, votre première session distante s'ouvre sur une question au lieu de démarrer le travail, et tout ce que vous envoyez en attendant tombe dans le vide.

On peut poser cette autorisation à l'avance, dans la configuration de l'agent sur l'hôte : hasTrustDialogAccepted pour le dossier dans ~/.claude.json, trust_level dans ~/.codex/config.toml. Fauconnier le fait avant le premier lancement, en n'ajoutant que ce champ, sans rien toucher s'il est déjà posé, et sans jamais bloquer l'ouverture si l'écriture échoue. Le pire cas reste la question à l'écran, et elle se répond d'une touche.

Détail 3 : les mots de passe ne se stockent pas

Un outil qui propose de retenir votre mot de passe SSH « pour vous simplifier la vie » vous crée un problème. La bonne posture est ennuyeuse et sûre : les clés sont gérées par votre agent SSH (ssh-add), et si SSH demande une phrase de passe, il vous la demande à l'écran, à vous, à ce moment-là. Rien à conserver, rien à fuiter.

Dans le même esprit, votre ~/.ssh/config contient déjà vos hôtes, leurs utilisateurs et leurs ports. Un outil correct s'en sert comme source au lieu de vous faire tout ressaisir, en ignorant les blocs génériques comme Host * : c'est une règle, pas une machine.

Détail 4 : savoir si l'hôte répond avant de le proposer

Proposer d'ouvrir un agent sur une machine injoignable donne une fenêtre qui met trente secondes à échouer. Une sonde courte en mode non interactif (BatchMode=yes, quelques secondes de délai) permet de griser ce qui ne répond pas.

Attention à ce que veut dire « grisé ». Une sonde non interactive échoue aussi quand la clé n'est pas chargée ou qu'un mot de passe est demandé. Grisé veut donc dire « pas joignable sans interaction », pas « machine morte ». Et « pas encore testé » n'est pas « injoignable » : n'interdisez que ce que vous avez vu échouer.

Quand ça ne marche pas : trois questions dans l'ordre

L'hôte répond-il sans rien demander ? Essayez ssh -o BatchMode=yes mon-serveur true. Si ça échoue, chargez la clé (ssh-add) ou connectez-vous une fois à la main pour accepter l'empreinte.
La session existe-t-elle encore ? ssh mon-serveur tmux ls liste les sessions vivantes. C'est l'information la plus fiable du lot, elle vient de tmux lui-même.
L'avez-vous rattachée, ou recréée ? Si vous voyez deux sessions là où vous en attendiez une, votre nom n'était pas stable (détail 1).

Faire le ménage

Une session tmux ne meurt pas toute seule, c'est tout son intérêt. Le revers : un agent oublié depuis trois jours tourne encore, et s'il a un abonnement derrière lui, il peut continuer à consommer. Prenez l'habitude d'un tmux ls de temps en temps, et fermez ce qui est fini avec tmux kill-session -t <nom>. Avec un préfixe commun pour tous vos agents, le ménage se fait d'un coup d'œil : tout ce qui commence par fauconnier- est à vous, le reste appartient à autre chose.

Ce que ça change dans la journée

Une fois la mécanique en place, la façon de travailler change plus qu'on ne l'imagine. Vous lancez une migration lourde avant d'aller déjeuner, vous fermez tout, et vous vous rebranchez depuis le canapé ou depuis le téléphone pour lire où elle en est et répondre à une question. Vos agents ne dépendent plus de la durée de vie de votre session graphique, mais de celle du serveur.

Le même principe marche sur votre propre Mac : si les agents locaux tournent dans tmux eux aussi, l'iPhone peut s'y rebrancher. C'est l'objet du guide Claude Code depuis l'iPhone.

Questions fréquentes

tmux ou screen pour un agent de code ?

Les deux gardent la session en vie. tmux est plus courant aujourd'hui, et son option new -A (créer ou rattacher) rend la commande idempotente, ce qui évite les sessions en double.

L'agent continue-t-il si je ferme mon Mac ?

Oui s'il tourne sur une autre machine dans tmux : la fermeture coupe seulement votre connexion. Un agent lancé sur le Mac lui-même s'arrête avec le Mac, sauf si le Mac reste allumé et que l'agent tourne dans tmux.

Faut-il installer l'agent sur le serveur ?

Oui. Le CLI (claude, codex, gemini…) doit être installé et connecté à votre compte sur la machine distante. Votre Mac ne fait qu'afficher le terminal.

Comment retrouver une session perdue ?

Lancez ssh mon-serveur tmux ls pour lister les sessions, puis rattachez-vous avec tmux attach -t suivi du nom. Si la session n'apparaît pas, l'agent ne tournait pas dans tmux.

Fauconnier fait tout ça pour vous. « Ouvre un agent claude sur falcon-prod » crée la fenêtre, monte le SSH, nomme la session tmux de façon stable, pose la confiance du dossier sur l'hôte et lit vos machines dans votre ~/.ssh/config. Aucun mot de passe n'est stocké. Et Perchoir, l'app iPhone gratuite, se rebranche sur les mêmes sessions.

Découvrir Fauconnier