Los agentes de VS Code ya pueden trabajar en tu Dev Container remotoLos agentes de VS Code ya pueden trabajar en tu Dev Container remoto

El agente necesita el mismo entorno que el proyecto

Un agente que ejecuta comandos en mi portátil no está trabajando realmente sobre mi proyecto si la aplicación vive en un servidor, una máquina virtual o WSL. Puede leer el código, pero fallará al usar una versión distinta de PHP, una extensión ausente, un composer diferente o servicios que solo existen en mi homelab. El problema no es el modelo: es la distancia entre el entorno donde piensa y el entorno donde debe comprobar el resultado.

VS Code 1.139 añade una opción útil para reducir esa distancia. Desde la ventana Agents, un agente puede ejecutar su sesión dentro del Dev Container de un proyecto situado en un host SSH, Tunnel o WSL. Eso significa que las operaciones sobre archivos y comandos ocurren dentro del contenedor configurado para ese repositorio, no en el equipo desde el que abro VS Code. (code.visualstudio.com)

Qué cambia en un homelab

En mi caso, esto encaja bien con proyectos Laravel que residen en un servidor del homelab. Si el Dev Container ya define PHP, Composer, Node y las dependencias del proyecto, el agente puede usar esas mismas herramientas para instalar paquetes, ejecutar pruebas o revisar una migración. No tengo que replicar la pila completa en el portátil solo para pedir una tarea al agente.

También sirve cuando el proyecto depende de servicios levantados alrededor del contenedor, como una base de datos, Redis o un servicio de correo de desarrollo. La condición es que el Dev Container y su red estén configurados para que el proyecto pueda alcanzar esos servicios, igual que cuando trabajo yo manualmente. El agente no obtiene acceso mágico al homelab: hereda el entorno y los permisos que tenga el contenedor.

La configuración mínima

La función está limitada a la ventana Agents de escritorio y requiere activar una opción experimental. Se puede habilitar desde la interfaz de configuración o dejarla explícita en el archivo de ajustes de VS Code. La clave documentada es esta:

{
  "chat.agentHost.devContainer.enabled": true
}

Además, el repositorio debe incluir una configuración de Dev Container en .devcontainer/devcontainer.json o en .devcontainer.json. Docker debe estar instalado, ejecutándose y disponible en el PATH de la máquina que contiene la carpeta del proyecto; si el proyecto está en un servidor remoto, Docker debe estar en ese servidor, no necesariamente en el portátil. (code.visualstudio.com)

Cómo iniciar la sesión

Abro la ventana Agents, creo una sesión nueva y selecciono la carpeta del proyecto remoto. En el selector de carpeta, despliego las opciones del workspace y elijo Use Dev Container antes de enviar el primer prompt. VS Code identifica la sesión con el sufijo - Dev Container, una señal útil para no olvidar dónde se están ejecutando realmente los comandos. (code.visualstudio.com)

Para un proyecto remoto, antes tengo que tener configurada la conexión correspondiente en la ventana Agents. La documentación contempla hosts SSH, Tunnel y WSL, pero el host también debe anunciar compatibilidad con Dev Containers para que la opción aparezca. Si no aparece, no sirve de nada activar la opción a ciegas: hay que revisar la conexión, Docker y la configuración del repositorio. (code.visualstudio.com)

La letra pequeña

Esto sigue siendo experimental y puede cambiar o desaparecer en versiones posteriores. Tampoco es una función general para cualquier ventana de VS Code: está disponible en la ventana Agents de escritorio. Conviene tratarla como una forma de probar un flujo de trabajo útil, no como una pieza cerrada de infraestructura. (code.visualstudio.com)

Las sesiones en Dev Container trabajan directamente sobre el workspace del contenedor y no se pueden combinar con New Worktree. La opción tampoco está disponible para hosts no compatibles ni para carpetas cuya fuente esté anidada dentro de otro entorno remoto. Si el contenedor no inicia, el lugar correcto para empezar a mirar es el canal específico de Dev Containers en la vista Output. (code.visualstudio.com)

Hay otra precaución más práctica: un agente que puede ejecutar pruebas también puede ejecutar comandos que consuman recursos, modifiquen datos de desarrollo o hablen con servicios accesibles desde el contenedor. Antes de usar aprobaciones automáticas, revisaría los montajes, las variables de entorno, las credenciales y el alcance de red de ese Dev Container. El aislamiento real depende de cómo haya sido construido el entorno, no del nombre de la función.

Un paso menos entre la petición y la validación

La parte interesante no es que el agente pueda abrir una terminal remota. Lo interesante es que puede trabajar con la misma definición reproducible del entorno que usa el proyecto, incluyendo sus versiones y dependencias. Para un homelab con varios proyectos, eso reduce configuraciones duplicadas y evita que el portátil se convierta en otra variante difícil de mantener.

No sustituye revisar cambios, ejecutar pruebas relevantes ni proteger servicios con datos importantes. Pero sí hace más razonable pedir tareas a un agente cuando el código vive lejos del equipo desde el que estoy trabajando. Si el Dev Container ya representa bien el entorno del proyecto, ahora puede representar también el entorno del agente. (code.visualstudio.com)

Fuente: GitHub Copilot weekly releases — September 21

Documentación oficial: Visual Studio Code 1.139