Garder Claude Code actif après une coupure SSH : la recette tmux

L'agent travaille sur ton serveur. Tu fermes le portable. À ton retour, il n'y a plus de processus à retrouver.

Nous avons reçu exactement cette demande : des sessions distantes persistantes qui survivent à une coupure du client, pour continuer depuis une autre machine. Notre lancement SSH exécutait déjà le CLI sur l'hôte. Cela ne suffisait pas : le processus dépendait encore du terminal SSH interactif.

Nous avons livré le changement dans AgentsRoom 1.198.0. Voici d'abord la recette à la main, puis ce que l'app en fait. Le même problème de durée de vie concerne Claude Code, Codex et les autres CLI de code interactifs.

Le terminal doit survivre à la connexion

Notre lancement distant ordinaire utilisait un canal SSH avec un terminal attaché. Si ce canal disparaît, l'hôte peut envoyer un signal de déconnexion et l'agent meurt. Un processus distant n'est pas automatiquement persistant.

tmux donne au processus un terminal qui vit sur l'hôte indépendamment de celui qui le regarde. Son guide de démarrage décrit précisément cet usage : protéger des programmes distants des coupures et y accéder depuis un autre ordinateur.

Il s'agit ici de garder un processus actif. Pour choisir entre une session cloud, une télécommande sur téléphone et ton propre serveur, lis les trois sens d'un agent distant.

Lance tmux avant l'agent

Sur un hôte de type Unix, connecte-toi avec ton alias SSH habituel. Remplace le chemin du dépôt par le tien :

ssh my-server
tmux -V
tmux new-session -s coding
cd ~/projects/my-repo
claude

Pour Codex, remplace la dernière ligne par codex. Le CLI doit être installé et connecté à ton compte sur le serveur. Commence dans un dépôt où tu peux expérimenter sans conséquence.

Détache-toi avec Ctrl+B, puis D. Reconnecte-toi plus tard :

ssh my-server
tmux list-sessions
tmux attach-session -t coding

Le manuel de tmux documente le détachement et le rattachement. Tu retrouves le terminal actif. Tu ne renvoies pas la tâche et tu ne lances pas un deuxième agent.

Vérifie le cycle avant de confier du vrai travail

Tu peux vérifier la recette sans consommer de quota d'agent. Dans la nouvelle session tmux, lance cette commande finie à la place d'un CLI :

python3 -u -c 'import time; [(print(i, flush=True), time.sleep(1)) for i in range(60)]'

Détache-toi, coupe SSH et rattache-toi dans la minute qui suit. Les nombres doivent avoir avancé pendant ton absence. C'est une procédure pour ton hôte, pas une mesure que nous aurions faite sur toutes les configurations de serveur.

Essaie ensuite une courte tâche d'agent. Après reconnexion, regarde les fichiers modifiés et s'il attend une réponse. Une session peut survivre pendant que l'agent attend une permission. Le garder actif ne le rend pas autonome.

Ce que nous avons changé dans AgentsRoom

Ouvre la connexion SSH enregistrée et active Garder les agents actifs sur cet hôte quand AgentsRoom se ferme. L'option est désactivée par défaut. L'hôte doit avoir tmux 3.0 ou plus récent.

Ouvre ensuite un projet distant et lance un agent dessus. Le CLI tourne dans une session tmux nommée sur l'hôte. Quitter AgentsRoom, mettre le portable en veille ou perdre la connexion laisse cette session tranquille. Ouvrir à nouveau le même agent enregistré s'y rattache, y compris depuis un autre ordinateur de ton compte.

Nous avons fait quatre choix techniques parce que chacun change un geste utilisateur :

• Le nom de session suit l'identité de l'agent. Rouvrir cet agent retrouve son processus ; un nouvel agent a une nouvelle session.
• L'app utilise un serveur tmux séparé et ignore ta configuration tmux personnelle. Elle ne réorganise pas les sessions que tu gères à la main.
• Le préfixe tmux est désactivé dans l'app. Ctrl+B reste disponible pour le CLI de code et Échap lui parvient sans le délai habituel de tmux.
• Redémarrer explicitement l'agent remplace le processus distant. Quitter l'app détache celui qui le regarde. Ces gestes doivent avoir des effets différents.

La dernière distinction compte le plus. Fermer l'onglet de l'agent n'est pas le geste pour le laisser travailler. Quitte l'app ou déconnecte-toi de sa vue. Si tu fermes ou redémarres explicitement l'agent, AgentsRoom tente aussi d'arrêter la session distante ; si l'hôte est injoignable, cet arrêt ne peut pas être garanti.

Si tmux manque ou est trop ancien, l'app lance l'agent comme avant. La case cochée ne prouve pas à elle seule la persistance : vérifie l'hôte et fais l'exercice de déconnexion. Ces détails de l'implémentation publiée ont été vérifiés le 7 octobre 2026.

La place de nohup et de Mosh

nohup fait ignorer les signaux de déconnexion à une commande, comme l'explique son manuel. Il ne donne pas un terminal interactif auquel se rattacher ensuite. Il convient mieux à une commande de traitement avec entrée et sortie redirigées qu'à un agent qui peut poser une question.

Mosh gère les connexions intermittentes et les changements de réseau. Sa documentation prévient aussi qu'il synchronise l'écran visible plutôt que tout l'historique défilant. Il peut s'utiliser avec tmux ; retrouver une session après avoir volontairement quitté le client est une autre question que changer de réseau en cours de route.

Ce que la persistance ne règle pas

L'hôte doit rester allumé. Un redémarrage met fin aux processus actifs. Une limite de quota, un plantage du CLI ou une question de permission peut encore bloquer le travail. Tu retrouves l'écran courant ; tout l'historique de console affiché sur l'autre ordinateur n'est pas promis à la reprise.

Garde le travail dans des fichiers que la prochaine session pourra lire : une courte note de tâche, les changements eux-mêmes et le résultat des vérifications. Un terminal qui survit est utile. Une tâche dont l'état n'existe que dans ce terminal reste fragile.

La page d'accès distant explique comment atteindre tes agents. Cette recette répond à la question suivante : reste-t-il un agent à atteindre quand la connexion a disparu ?

Questions fréquentes

Un agent de code sur un serveur survit-il à une coupure SSH ?

Un simple terminal SSH interactif ne garantit aucune persistance. Perdre son terminal peut arrêter l'agent. Lance-le dans tmux sur le serveur avant de te déconnecter, puis rattache-toi à cette session. Le serveur doit rester allumé et l'agent peut toujours s'arrêter pour ses propres raisons.

Puis-je me reconnecter depuis un autre ordinateur ?

Oui, connecte-toi au même serveur avec le même utilisateur de l'hôte et rattache-toi à la session tmux nommée. Dans AgentsRoom, active les sessions persistantes de la connexion SSH, puis ouvre le même agent enregistré depuis un autre ordinateur de ton compte. Un nouvel agent crée une autre session.

Se reconnecter revient-il à reprendre une conversation ?

Non. Se rattacher à une session tmux active retrouve un processus qui n'a jamais été arrêté. Reprendre une conversation enregistrée lance un processus qui relit l'historique du CLI. Un fichier de conversation ne restaure ni une commande en cours ni un processus de terminal mort.

Fermer AgentsRoom arrête-t-il un agent distant persistant ?

Quitter l'app le laisse actif si l'option de sessions persistantes de la connexion SSH est activée et si l'hôte dispose de tmux 3.0 ou plus récent. Fermer ou redémarrer explicitement l'agent demande l'arrêt ou le remplacement de son processus ; un hôte injoignable ne peut pas confirmer cette action. Sans tmux compatible, le lancement revient au comportement SSH habituel.