Desde VS Code 1.144 (28 de octubre de 2026), Copilot en VS Code corre por defecto en el Agent Host, un proceso aparte: cerrar la ventana ya no detiene al agente, y puedes seguirlo desde GitHub Mobile.
Es el cambio que GitHub anunció en Universe. Parece pequeño, pero cambia el día a día con agentes: lanzas un refactor largo, cierras el proyecto, te alejas del escritorio y lo sigues desde el teléfono. Aquí va qué es el Agent Host, qué sobrevive realmente cuando cierras cosas, cómo llegar a tu sesión desde otro dispositivo y qué concesiones de seguridad trae.
¿Qué es el Agent Host de Copilot en VS Code?
El Agent Host es un proceso dedicado, separado de cualquier ventana de VS Code, que ejecuta los harnesses de agentes (Copilot, Claude y Codex) y es dueño de sus sesiones. Como la sesión vive fuera de la ventana, una misma sesión puede mostrarse en varias ventanas a la vez y sigue corriendo cuando la ventana que la inició desaparece.
Habla el Agent Host Protocol (AHP), que es abierto: VS Code, el Agents window y cualquier cliente que construyas tú son simplemente clientes de la misma sesión en vivo.
El harness de Copilot dentro del Agent Host está construido sobre el Copilot SDK, el mismo runtime que usan Copilot CLI y la app de GitHub Copilot. El objetivo declarado de GitHub es que el agente se comporte igual en los tres productos. (Explicamos por qué el SDK importa a nivel estratégico en GitHub Copilot Ya No Quiere Ser un Copilot.)
¿Copilot en VS Code ya usa el Agent Host por defecto?
Sí, en las sesiones nuevas. El harness de Copilot es el predeterminado para sesiones nuevas tanto en el editor como en el Agents window, y corre a través del Agent Host.
Eliges el harness en el control Session Target antes de tu primer prompt. Las demás opciones siguen ahí:
| Harness | Dónde corre | Al cerrar la ventana |
|---|---|---|
| Copilot | Agent Host (Copilot SDK) | La sesión sigue corriendo |
| Local | Extension host de VS Code | La sesión se detiene |
| Claude | Claude Agent SDK, integrado en VS Code | — |
| Codex | Extensión OpenAI Codex, o la integración experimental con el Agent Host | — |
El harness Local es el comportamiento anterior: la ventana es dueña de la sesión, así que cerrarla detiene el trabajo.
¿La sesión sigue corriendo si cierro VS Code?
Si cierras la ventana, sí. Si sales de la aplicación, no, al menos en las sesiones gestionadas por VS Code de escritorio en tu propia máquina. La documentación es explícita: cerrar una ventana del editor no es lo mismo que salir de la aplicación, y para las sesiones locales del Agent Host tienes que mantener VS Code abierto.
Dos reglas más que conviene conocer:
- Reconectarte a una sesión no significa que el trabajo haya continuado mientras el host estaba detenido o la máquina apagada. Si la laptop se suspendió, el agente también.
- Desconectar un cliente no detiene una tarea en curso. Para frenar al agente, usa la acción de detener de la sesión.
Si necesitas trabajo que sobreviva a cerrar la laptop, eso es otro producto: las sesiones cloud, que se inician desde el Agents window, corren en la infraestructura de GitHub y se pueden continuar desde VS Code, la app de Copilot, GitHub Mobile, github.com o Copilot CLI.
¿Cómo controlar Copilot desde el celular?
Registras tu máquina como un GitHub Environment, y desde ese momento cualquier cliente con la misma cuenta de GitHub, incluido GitHub Mobile, puede ver y trabajar con las sesiones de esa máquina. Al momento de publicar esta nota, GitHub Environments está en Preview.
Según la documentación de VS Code:
- En la máquina donde está tu workspace, abre Remote Connections desde la barra de título del Agents window o desde el área de entrada del Chat view.
- Selecciona GitHub Environments. Con eso empieza a compartirse. Completa los avisos de inicio de sesión o confirmación que aparezcan.
- Si quieres, renombra el environment para reconocerlo en otros dispositivos.
La función se controla con el setting chat.agentHost.githubEnvironments.enabled.
El changelog de GitHub describe una ruta por terminal para lo mismo: abre una terminal en la máquina, entra en la carpeta del proyecto y ejecuta:
code agent host --github-environment
Para conectarte desde otro VS Code (u otro cliente de escritorio), inicia sesión con la misma cuenta de GitHub, ejecuta Connect to Environment… desde la Command Palette, elige la máquina y selecciona la sesión existente. Usa Refresh Environments si no aparece.
Desde el teléfono, según GitHub, puedes revisar el progreso, dar indicaciones o iniciar tareas nuevas en tu máquina de desarrollo. Al momento de publicar esta nota, ni GitHub ni la documentación de VS Code habían publicado instrucciones paso a paso para el lado de GitHub Mobile, y la documentación aclara que las acciones disponibles varían según el cliente.
Para dejar de compartir, abre Remote Connections en el host y selecciona Off.
La condición no cambia nunca: la máquina y su Agent Host tienen que seguir corriendo.
¿Cómo correr el agente en otra máquina con VS Code Remote SSH o un tunnel?
El Agents window puede conectarse a un Agent Host en la misma máquina o en un host por SSH, dev tunnel o WSL. El agente usa entonces el código, las herramientas y las dependencias de esa máquina, y sigue corriendo aunque te desconectes o cierres VS Code en local.
Por SSH
Selecciona New (Ctrl+N en Windows/Linux, ⌘N en macOS), elige SSH en el desplegable de environments e ingresa un connection string como user@hostname. VS Code instala el CLI necesario en la máquina remota cuando hace falta.
Con un vscode tunnel (dev tunnels)
En la máquina remota, ejecuta code tunnel (o code-insiders tunnel) y autentícate la primera vez. Luego selecciona New, elige Dev Tunnels, el tipo de cuenta y el tunnel. También puedes levantar un host independiente directamente con code agent host --tunnel.
Desde el navegador
Con un tunnel corriendo, abre https://insiders.vscode.dev/agents, elige Continue with GitHub y selecciona tu host. El navegador se conecta solo a través de dev tunnels o GitHub Environments, no directamente por SSH.
La máquina remota tiene que estar encendida y accesible. Conectarte a una máquina apagada no la enciende.
¿Es seguro exponer tu máquina así?
Es un modelo de propietario de confianza, y la documentación es directa sobre las concesiones:
- Las acciones de la sesión se replican en GitHub, y el contenido de la conversación no tiene cifrado de extremo a extremo.
- Cualquier cliente conectado obtiene acceso de propietario a las sesiones, herramientas y recursos del workspace del host.
- Un dev tunnel anónimo permite que cualquiera que encuentre la URL inicie sesiones de agente en tu máquina. Exige siempre autenticación con GitHub o Microsoft.
Si la máquina guarda credenciales o código de clientes que no puedes exponer, combínalo con el sandbox local, que llegó a disponibilidad general el 7 de octubre para las sesiones del Agent Host: Sandbox local de GitHub Copilot.
¿Copilot CLI o VS Code: qué cambia con el Agent Host?
La diferencia se achica. El harness de Copilot en VS Code usa el mismo Copilot SDK que Copilot CLI, y una máquina registrada como GitHub Environment expone sus sesiones también a Copilot CLI. Puedes empezar en el editor y retomar desde la terminal, o al revés.
Instalar Copilot CLI también pasa por VS Code: en Windows, desde el instalador de VS Code; en macOS, al agregar VS Code al PATH; en Linux, ejecutando copilot.
Lo que no cambia: el SDK compartido no garantiza herramientas, modelos, permisos ni personalizaciones idénticos entre productos. Elige por interfaz, no esperes paridad total.
¿Qué no funciona igual que con el harness Local?
El harness de Copilot no reemplaza sin más cada flujo de trabajo del harness Local. La documentación enumera estas limitaciones:
- Las sesiones del harness de Copilot no tienen acceso a todas las herramientas integradas o aportadas por extensiones.
- No todas las sesiones ni todos los settings personales se sincronizan.
- Las herramientas de extensiones solo funcionan en chats de la ventana del editor donde corre esa extensión.
Antes de mover un flujo del que dependes, revisa que sus herramientas y servidores MCP estén disponibles en el harness de Copilot. Si no lo están, el harness Local sigue a un clic en Session Target.
¿Copilot puede usar tus apps de escritorio (Copilot computer use)?
De forma experimental, sí, en macOS y Windows. Activa chat.agentHost.computerUse.enabled en Settings, reinicia VS Code y ejecuta /computer on en una sesión de Copilot que corra en tu computadora (/computer off lo vuelve a apagar). Cada aplicación requiere tu aprobación; en macOS concedes los permisos del sistema una sola vez. La configuración se comparte con Copilot CLI y la app de GitHub Copilot, y las organizaciones pueden desactivarla por política.
¿Puedes construir tu propio cliente para el Agent Host?
Sí, para eso es el protocolo abierto. El Agent Host Protocol v1.0 ya está publicado. Ejecuta code agent host para levantar un host independiente en localhost, protegido con un connection token, y conéctate con una de las librerías cliente para TypeScript, Rust, Go, Kotlin o Swift. Si VS Code ya tiene un host corriendo, code agent endpoints devuelve sus endpoints.
Estado al 3 de noviembre de 2026: el Agent Host y el harness de Copilot por defecto están publicados en la 1.144, sin etiqueta de preview. GitHub Environments está en Preview. Computer use, las sesiones cloud y los Dev Containers en el Agent Host son experimentales.
¿Y tú? ¿Qué tarea le dejarías a Copilot corriendo mientras te alejas del escritorio?
- En mi máquina, con la ventana del editor abierta
- En un servidor remoto, por SSH o tunnel
- En la nube, con un cloud agent
- Prefiero otra opción (cuéntanos cuál)
Comenta abajo o, si este artículo te llegó por correo, responde directamente al email: tu respuesta se publica aquí.
Relacionado: Sandbox local de GitHub Copilot: cómo activarlo en la CLI, la app y VS Code (y qué no bloquea)