Mosh ou SSH sur ton téléphone : lequel pour suivre ton agent
Tu lances Claude Code sur une longue tâche, tu fermes le portable et tu sors. Le train entre dans un tunnel, ton téléphone passe du Wi-Fi au réseau mobile et perd le signal pendant une minute, et quand tu regardes à nouveau, la session SSH est morte. C’est normal : SSH n’a jamais été conçu pour un client qui change de réseau toutes les quelques minutes, et Mosh et Eternal Terminal existent exactement pour ça.
Voici ce que fait chacun, ce qui se passe sur un téléphone et comment choisir. Si tu veux la vue d’ensemble pour lancer un agent depuis ta poche, commence par Comment utiliser Claude Code depuis ton téléphone.
Ce qui arrive à SSH sur un téléphone
SSH fonctionne sur une connexion TCP, et cette connexion est liée à une adresse IP et à une paire de sockets. Quand ton téléphone passe du Wi-Fi au réseau mobile, son IP change et le serveur ne le sait jamais. La connexion se fige jusqu’à ce qu’un timeout la tue. La même chose arrive quand iOS ou Android coupe le réseau de l’app pour économiser la batterie, ou tue l’app parce qu’il a besoin de mémoire.
Tu perds plus que l’écran. Un processus accroché à cette session SSH peut recevoir un SIGHUP et mourir avec elle. C’est pourquoi un agent lancé directement depuis un shell SSH est fragile, et pourquoi le compagnon de cet article, tmux pour agents de code, est presque obligatoire.
Mosh : UDP et reconnexion silencieuse
Mosh (mobile shell) n’utilise SSH que pour démarrer. Il s’authentifie en SSH, lance mosh-server sur ton ordinateur, puis parle en UDP. Sans connexion TCP à casser, le client peut changer d’IP, perdre le signal ou se mettre en veille, et quand le réseau revient la session est toujours là.
Concrètement :
- Tu passes du Wi-Fi au réseau mobile et la session ne le remarque pas.
- Si le serveur cesse de répondre, l’app te le dit au lieu de fermer la session.
- Écho local avec prédiction : ce que tu tapes s’affiche immédiatement, souligné, et est confirmé quand le serveur répond. Sur une liaison mobile à forte latence, tu sentiras la différence.
Ce que ça coûte :
- Les ports UDP 60000–61000 doivent être ouverts sur ton ordinateur (chaque session prend un port de cette plage).
- Pas d’historique de défilement. Mosh ne synchronise que ce qui est à l’écran. Si tu veux remonter lire ce que l’agent a affiché, travaille dans tmux.
- Si l’OS tue l’app, la session Mosh se termine et ne peut pas être reprise.
Eternal Terminal : TCP, mais ça reprend
Eternal Terminal (ET) prend l’autre direction. Il fonctionne sur TCP, sur le port 2022 par défaut, mais garde son propre état de session, donc quand la connexion tombe il la reconstruit et renvoie ce qui a été manqué. Il lui faut etserver en marche sur ton ordinateur et etterminal dans le PATH de la session SSH.
Sur un téléphone, son avantage est d’être le seul transport de Wendo qui survit à la fermeture de l’app. La session apparaît dans Accueil et reprend là où elle en était quand tu l’ouvres. Wendo présente ET comme expérimental, garde-le en tête avant de t’y fier.
Comparaison rapide
| | SSH | Mosh | ET |
|---|---|---|---|
| Transport | TCP | UDP | TCP (2022) |
| Wi-Fi ↔ réseau mobile | Coupe | Survit | Survit |
| Téléphone en veille | Coupe | Survit | Survit |
| App tuée par l’OS | Coupe | Perdue | Reprend |
| Historique de défilement | Oui | Non | Oui |
| Avec un Jump Host dans Wendo | Oui | Non | Non |
Installer mosh-server
Sur l’ordinateur où tourne l’agent :
# macOS
brew install mosh
# Debian / Ubuntu
sudo apt install mosh
# Fedora
sudo dnf install mosh
Vérifie qu’il est dans le PATH d’une connexion SSH ordinaire, pas seulement dans ton terminal interactif :
ssh my-server 'which mosh-server'
Sur un Mac Apple Silicon, Homebrew le place dans /opt/homebrew/bin/mosh-server, qui n’est pas toujours dans le PATH d’une session non interactive. Dans ce cas, Wendo te permet de définir le chemin de mosh-server dans la connexion.
Notes sur le pare-feu
Mosh a besoin des ports UDP entrants 60000–61000. Sous Linux avec ufw :
sudo ufw allow 60000:61000/udp
Avec firewalld :
sudo firewall-cmd --permanent --add-port=60000-61000/udp
sudo firewall-cmd --reload
Si ton ordinateur est derrière un routeur, redirige cette plage UDP comme tu redirigerais le port 22. Pour ET, ouvre le port TCP 2022 de la même façon (sudo ufw allow 2022/tcp).
Si ton SSH passe par un proxy ou un répartiteur de charge, l’UDP de Mosh peut être envoyé à la mauvaise IP. Wendo a une option « Utiliser l’adresse IP du serveur pour UDP » pour ce cas.
Choisir dans Wendo
Quand tu modifies une connexion, le champ Transport propose Auto, SSH, MOSH et ET. Avec Auto, Wendo essaie Mosh d’abord, puis ET, et se rabat sur SSH si aucun n’est disponible. Commence par Auto.
Une règle pratique :
- Tu vas te déplacer avec le téléphone et les sessions durent quelques minutes : Mosh.
- Tu veux fermer l’app, revenir une heure plus tard et retrouver la session dans Accueil : ET.
- Tu te connectes via un Jump Host : SSH. Ni Mosh ni ET ne fonctionnent avec un Jump Host dans Wendo.
- Ton ordinateur ne peut pas ouvrir de ports UDP : ET ou SSH.
Mosh et Eternal Terminal font partie de Wendo Pro ; sans Pro, la connexion passe par SSH. Les champs sont décrits dans les docs des sessions.
Quel que soit le transport, lance l’agent dans tmux. Le transport garde l’écran en vie ; tmux garde le processus en vie et te donne l’historique de défilement qui manque à Mosh. La combinaison habituelle est Mosh ou ET pour le fil et tmux pour le travail, et voici le minimum de tmux dont tu as besoin. Pour recevoir des alertes quand l’agent demande une permission, vois les hooks.