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

Vous lancez une tâche longue à un agent, vous fermez votre portable, vous prenez le train : l'agent est mort avec la session. La parade est ancienne, robuste, et n'a besoin d'aucun service tiers — SSH plus tmux. Voici la recette, et les quatre détails qui font la différence entre « ça survit » et « je ne retrouve rien ».

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. Rien de tout cela ne dépend de l'agent ; c'est la façon dont les terminaux fonctionnent.

La solution consiste donc à déplacer le terminal, pas l'agent : il doit vivre sur une machine qui, elle, ne ferme pas, et votre écran ne fait que s'y brancher.

La recette de base

Sur une machine distante joignable en SSH :

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

Trois morceaux, chacun indispensable :

• ssh -t — force un vrai terminal côté serveur ; sans ça, 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, s'y rattache si elle existe déjà. C'est ce petit -A qui transforme la commande en « ouvre ou reprends ».
• claude — l'agent lui-même, qui tourne désormais dans tmux, donc à l'abri de la fin de votre connexion.

Fermez le portable : tmux continue sur le serveur. Rouvrez la même commande demain, depuis un autre Mac : vous retombez dans la session en cours, scrollback compris.

Détail 1 — Le nom de session doit être déterministe

C'est l'erreur la plus fréquente. Si le nom contient l'heure, un identifiant aléatoire ou le numéro de fenêtre, alors -A ne rattache jamais rien : il crée une session de plus à chaque tentative, et vous accumulez des agents fantômes qui consomment vos quotas. Un nom stable, dérivé de ce que vous ouvrez (agent-claude, agent-codex), suffit — avec un suffixe numéroté seulement si vous en voulez volontairement deux du même type.

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 de confiance au lieu de commencer le travail. Poser cette autorisation à l'avance, en écrivant le fichier de configuration de l'agent sur l'hôte, fait gagner ce round-trip à chaque nouveau serveur.

Détail 3 — Les mots de passe ne se stockent pas

Un outil qui vous 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, et si SSH demande une phrase de passe, il 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 plutôt que de vous faire ressaisir tout ça — en ignorant les blocs génériques (Host *), dont les options ne doivent pas fuiter vers la machine suivante.

Détail 4 — Savoir si l'hôte répond, avant de proposer

Proposer d'ouvrir un agent sur une machine injoignable produit une fenêtre qui met trente secondes à échouer. Une sonde courte (BatchMode=yes, résultat gardé une minute) permet de griser ce qui ne répond pas. Nuance utile : « pas encore testé » n'est pas « injoignable » — n'interdisez que ce que vous avez vraiment vu échouer.

Ce que ça change dans la journée

Une fois la mécanique en place, le mode de travail change plus qu'on ne l'imagine : vous lancez une migration lourde avant de partir déjeuner, vous fermez tout, et vous rebranchez depuis le canapé ou depuis le téléphone pour lire où ça en est et débloquer une question. Vos agents ne sont plus liés à la durée de vie de votre session graphique — ils sont liés à celle du serveur.