Cómo transmitir terminales PTY remotos al navegador en tiempo real con WebSocket
Ejecutar Claude Code en una máquina en la nube requiere un contenedor. Observarlo desde un navegador exige una conexión saliente desde el sandbox, contrapresión medida en el socket del navegador y un marco de cierre explícito.
Mover un agente a una máquina en la nube es la mitad fácil, y es de la que todo el mundo escribe: un contenedor, una imagen y una CLI dentro. La mitad que decide si el producto es utilizable es la conexión entre esa máquina y el navegador que la observa, y falla de dos maneras silenciosas.
La pantalla deja de ser el entorno de ejecución
La razón para mover un agente fuera de tu portátil no es que el portátil sea lento, sino que la ejecución deja de pertenecer a un dispositivo físico. El proceso del agente vive en la máquina que operamos; tu navegador solo envía pulsaciones y dibuja lo que recibe.
Esa frase sitúa una conexión de red en el centro del producto. Cada pulsación y cada byte de salida cruza ahora una red sujeta a retrasos y desconexiones.
El sandbox inicia la conexión saliente
La máquina que ejecuta los agentes no tiene un punto de entrada público. Abre una conexión hacia el plano de control y la mantiene, multiplexando todos los navegadores sobre ese enlace.
Esto significa que los fallos relevantes no tratan sobre la accesibilidad inicial, sino sobre lo que ocurre en un enlace activo que se degrada.
Primer fallo silencioso: medir el socket incorrecto
Un agente que compila un proyecto con abundante salida genera texto más rápido de lo que un navegador puede renderizarlo. Alguien debe frenar al productor.
Medir el socket local del sandbox es un error, ya que su enlace con el plano de control es rápido y acepta todo de inmediato. El socket congestionado es el del navegador en el otro extremo.
La detección debe ocurrir en el lector lento y la contrapresión debe viajar hacia atrás. El plano de control detiene la lectura del sandbox cuando el navegador se retrasa, permitiendo que TCP ajuste la ventana de recepción.
Retener lecturas en un enlace compartido bloquea a los demás espectadores. Por tanto, las retenciones solo deben durar milisegundos y el control individual de velocidad corresponde al plano de control.
Segundo fallo silencioso: un ping que siempre responde
Un ping WebSocket estándar recibe respuesta de la pila de red del sistema operativo, no de la aplicación. Una pestaña cerrada o un ordenador suspendido seguirán respondiendo durante un tiempo.
El extremo que termina el socket del navegador es el único que sabe si el usuario se ha ido, por lo que lo comunica explícitamente sobre el enlace.
Por qué esto no es un detalle secundario
Cualquiera puede meter una CLI en un contenedor. Lo que decide si los desarrolladores confían en dejar agentes trabajando es si la conexión es honesta sobre su estado.
El tablero de reservas que evita colisiones se detalla en un artículo propio, y la separación de secretos en un tercero.
Respuestas directas
¿Puede Claude Code seguir ejecutándose tras cerrar mi portátil?
Sí, cuando el proceso del agente y su repositorio están en una máquina en la nube. El navegador solo envía pulsaciones y muestra lo devuelto.
¿Necesita un agente en la nube un puerto abierto en mi red?
No. El sandbox inicia una conexión saliente con el plano de control y la mantiene abierta, igual que los ejecutores de CI autoalojados.
¿Qué ocurre con la tarea si el navegador que la observa se desconecta?
La tarea continúa. El componente que gestiona el socket del navegador avisa explícitamente al sandbox para no enviar datos al vacío.