Observer un terminal que vous n’hébergez pas
Faire tourner Claude Code sur une machine cloud demande un conteneur. L’observer depuis un navigateur nécessite une liaison sortante depuis la sandbox, une contre-pression mesurée sur le socket du navigateur et une trame explicite de fermeture.
Déplacer un agent vers une machine cloud est la moitié simple, et c’est celle dont tout le monde parle. Un conteneur, une image, un CLI à l’intérieur. La moitié qui détermine si le produit est utilisable est la liaison entre cette machine et le navigateur qui l’observe, et elle échoue de deux manières qu’aucun test ne remarque et qu’aucun utilisateur ne rapporte correctement.
L’ordinateur portable n’est plus le moteur d’exécution
La raison de déplacer un agent hors de votre portable n’est pas un manque de puissance. C’est que l’exécution cesse d’appartenir à un appareil physique. Le processus de l’agent et son dépôt vivent sur la machine que nous opérons, votre navigateur transmet les frappes et dessine ce qui revient. Fermer l’écran interrompt l’observation mais pas le travail.
Cette phrase place une liaison réseau au cœur du produit. Chaque frappe clavier et chaque octet de sortie traverse désormais un réseau susceptible de ralentir, de caler ou de disparaître sans prévenir.
La sandbox initie la connexion sortante
La machine exécutant les agents n’a aucun point d’entrée public. Elle ouvre une connexion vers le plan de contrôle et la maintient active, multiplexant tous les navigateurs connectés sur ce lien unique. C’est le modèle éprouvé des runners de CI auto-hébergés : rien à exposer, rien à rediriger, et fonctionnement immédiat derrière tout NAT.
Cela implique que les pannes intéressantes ne concernent pas l’accessibilité, mais ce qui se produit sur un lien établi qui se dégrade.
Première défaillance silencieuse : mesurer le mauvais socket
Un agent compilant un projet verbeux produit du texte plus vite qu’un navigateur ne peut le rendre. Il faut ralentir le producteur. L’approche naïve consiste pour la sandbox à surveiller son propre socket : si le tampon grossit, on arrête d’écrire.
C’est une erreur de mesure. Le socket de la sandbox est relié au plan de contrôle, qui est une machine rapide sur un réseau optimal acceptant tout immédiatement. Le socket engorgé est en réalité celui du navigateur, à l’autre bout, géré par un processus distinct.
La détection doit s’opérer là où se trouve le lecteur lent, et la pression doit remonter en sens inverse. Le plan de contrôle surveille le socket du navigateur ; dès que celui-ci prend du retard, il cesse de lire la liaison avec la sandbox. TCP s’occupe du reste : la fenêtre de réception se ferme, le tampon de la sandbox augmente enfin, déclenchant l’arrêt d’écriture à la source.
Retenir les lectures sur un lien partagé bloque les autres navigateurs. Un lien saturé signale une congestion globale, jamais la lenteur d’un seul spectateur. La rétention ne doit durer que quelques millisecondes, la limitation par spectateur restant la responsabilité du plan de contrôle.
Seconde défaillance silencieuse : un ping qui répond toujours
Vérifier la présence d’un client par un ping WebSocket est inopérant ici. Un ping reçoit une réponse de la pile réseau sous-jacente et non de l’application. Un onglet fermé, un ordinateur en veille ou une page plantée continuent de répondre aux pings pendant un temps.
Le composant terminant le socket du navigateur est le seul à savoir avec certitude si le navigateur est parti. Il le notifie explicitement sur la liaison interne. Quand le lien meurt, chaque session active est fermée localement pour éviter qu’un terminal ne diffuse dans le vide.
Ces règles évitent les fuites mémoire invisibles sur des machines délaissées et les sessions qui paraissent actives alors que l’utilisateur est parti depuis une heure.
Pourquoi ce n’est pas un détail
N’importe qui peut placer un CLI dans un conteneur. Ce qui incite les utilisateurs à laisser tourner leurs agents est la certitude que la liaison est transparente sur son propre état : elle détecte la congestion, identifie le départ du spectateur et agit en conséquence.
Le tableau de réservation évitant les collisions entre agents fait l’objet d’un article dédié. L’isolation des secrets hors de la machine d’exécution en forme un troisième. Celui-ci décrit le lien invisible entre les deux.
Réponses directes
Claude Code peut-il continuer à tourner après la fermeture de mon ordinateur portable ?
Oui, car le processus de l’agent et sa copie de travail résident sur une machine cloud. Le navigateur ne fait qu’envoyer les frappes et afficher les caractères retournés.
Un agent cloud nécessite-t-il un port ouvert sur mon réseau ?
Non. La sandbox initie une connexion sortante vers le plan de contrôle et la maintient ouverte, selon le modèle des runners auto-hébergés sans point d’entrée public.
Qu’advient-il d’une exécution quand le navigateur qui l’observe se déconnecte ?
L’exécution continue. Le côté qui gère le socket du navigateur prévient explicitement la sandbox, car un ping WebSocket classique continuerait de répondre pour un onglet fantôme.