Cómo usar Dev Containers con agentes de IA en VS Code (sin darle tu laptop entera)

AI Dev Tools — General
, , , , ,
1

VS Code ya puede ejecutar una sesión de agente de IA dentro del Dev Container de tu proyecto: el agente compila, prueba e instala con las herramientas del proyecto, no con lo que tengas en tu máquina. Llegó con VS Code 1.138 (16 de septiembre de 2026), se inicia con la acción Use Dev Container en la ventana de agentes (Agents window) y requiere Docker.

Estado al 21 de septiembre de 2026: la documentación de VS Code marca la función como experimental y el ajuste que la controla viene desactivado por defecto. Las notas de la versión indican que se está habilitando de forma gradual, así que es posible que todavía no la tengas activa; puedes activarla a mano (ver abajo). La Agents window, el único lugar donde funciona, está en Preview.

¿Por qué ejecutar un agente de IA dentro de un Dev Container?

Porque un agente que corre en tu máquina usa tu Node, tu Python, tus compiladores y tus paquetes globales, y lo hace con los permisos de tu usuario. Eso genera dos problemas.

El primero es la deriva de entorno. El “funciona” del agente vale lo que vale su entorno: si tu máquina tiene Node 22 y el proyecto fija Node 20, el agente puede pasar pruebas que tu CI va a rechazar.

El segundo es el alcance. La propia documentación de sandboxing de VS Code advierte que los comandos de terminal del agente pueden ejecutar procesos con los mismos permisos de sistema operativo que tu cuenta de usuario.

Un Dev Container resuelve el primero de raíz: el entorno se define en el repositorio, es igual para todo el equipo y el agente lo hereda. También ayuda con el segundo, aunque no del todo; la sección de seguridad más abajo explica los límites.

¿Qué es un Dev Container y qué va en devcontainer.json?

Un Dev Container es un contenedor Docker descrito por un archivo devcontainer.json dentro de tu proyecto, que le indica a VS Code qué imagen, herramientas y runtimes debe tener el entorno de desarrollo. El formato es una especificación abierta (containers.dev), así que no te ata a VS Code.

La configuración va en .devcontainer/devcontainer.json, o en .devcontainer.json en la raíz del proyecto. El ejemplo mínimo de la documentación de VS Code simplemente apunta a una imagen precompilada:

{
  "image": "mcr.microsoft.com/devcontainers/go:1"
}

No hace falta escribirlo a mano. La extensión Dev Containers (ms-vscode-remote.remote-containers) incluye el comando Dev Containers: Add Dev Container Configuration Files…, que genera el archivo a partir de una plantilla, de un Dockerfile existente o de un archivo de Docker Compose.

Si todavía no trabajas con contenedores en tu día a día, en yoDEV tenemos una guía previa sobre entornos de desarrollo consistentes con Docker.

¿Cómo se usan los Dev Containers con agentes de IA en VS Code?

Necesitas Docker en ejecución, una configuración de Dev Container en la carpeta y un ajuste activado.

1. Revisa los requisitos. Docker instalado y en ejecución, con la CLI de Docker disponible en el PATH. La carpeta local debe contener .devcontainer/devcontainer.json o .devcontainer.json.

2. Activa el ajuste. Abre Settings, busca chat.agentHost.devContainer.enabled y actívalo. Es un ajuste de aplicación, no de workspace.

3. Abre la Agents window. Tienes tres opciones:

  • Haz clic en Open in Agents en la barra de título.
  • Ejecuta Chat: Open Agents window desde la paleta de comandos.
  • Ejecuta code --agents desde una terminal.

4. Inicia una sesión dentro del contenedor.

  1. Selecciona New.
  2. En el selector de workspace, despliega el menú de tu carpeta y elige Use Dev Container. La etiqueta del workspace suma el sufijo “- Dev Container”.
  3. Si cambias de idea antes de empezar, elige Use Local en el mismo menú.
  4. Elige un harness, configura la sesión y escribe tu prompt.

A partir de ahí, el Agent Host (el proceso que ejecuta el agente) corre dentro del contenedor, mientras la Agents window sigue en tu máquina. Según la documentación del Agent Host, las ediciones de archivos y los comandos se ejecutan en el entorno que contiene al host.

¿Por qué no aparece la opción “Use Dev Container”?

Las causas más probables son cuatro:

  • El ajuste no está activado. Por el despliegue gradual, puede seguir apagado en tu instalación.
  • La carpeta no tiene una configuración de Dev Container compatible.
  • Docker no está en ejecución, o su CLI no está en el PATH.
  • Estás en la vista de chat normal. La acción solo existe en la Agents window.

Si el contenedor no arranca, abre el panel Output y selecciona el canal Dev Container del workspace: ahí están los registros de configuración y conexión.

¿Funciona con Claude y Codex, o solo con Copilot?

El Agent Host está pensado para varios harnesses: su documentación muestra adaptadores para Copilot, Claude y Codex. Los pasos para Dev Containers solo indican que elijas un harness disponible.

Al 21 de septiembre de 2026, la documentación no detalla qué harnesses están confirmados dentro de un contenedor, así que prueba el tuyo antes de depender de él.

¿Funciona en Windows?

Sí, a través de Docker Desktop:

  • Windows 10 Pro/Enterprise: Docker Desktop 2.0 o superior.
  • Windows 10 Home: Docker Desktop 2.3 o superior con el back-end de WSL 2.
  • Linux: Docker CE/EE 18.06 o superior. El paquete snap de Docker en Ubuntu no está soportado.

Dos cosas no funcionan en Windows: las imágenes de contenedores Windows y Docker Toolbox.

¿Qué limitaciones tiene?

  • Sin worktrees. Una sesión en Dev Container trabaja directamente sobre el workspace del contenedor y no se puede combinar con New Worktree. Pierdes el patrón de “dejar que el agente trabaje en una copia aislada de la rama”.
  • Una sola carpeta. La Agents window todavía no soporta sesiones multi-root.
  • Estado experimental. El comportamiento y los ajustes pueden cambiar entre versiones.

¿Un Dev Container es un sandbox para el agente?

La mirada de Grego:

Es una frontera real, pero no hay que confundirla con una bóveda. Yo usaría esta función, y a la vez sería claro con mi equipo sobre lo que aporta y lo que no.

Lo que aporta. La propia documentación de sandboxing de Microsoft pone a los Dev Containers por encima del sandbox de terminal, que es más liviano: aclara que el sandboxing de terminal no reemplaza el aislamiento que ofrecen las sesiones en la nube o los Dev Containers. Los comandos del agente se ejecutan contra el sistema de archivos y las herramientas del contenedor, no contra tu directorio personal, tus paquetes globales ni tus otros proyectos.

Lo que no aporta.

  • Tus archivos del proyecto siguen expuestos. Una carpeta local abierta en un Dev Container normalmente se monta desde tu disco (bind mount), así que las ediciones del agente pueden llegar a tus archivos reales. Sumado a que no hay opción de worktree, un mal turno del agente edita tu checkout, no una copia.
  • Tus credenciales pueden viajar contigo. La documentación de Dev Containers indica que, si usas un gestor de credenciales de Git, el contenedor probablemente ya tenga acceso a ellas. Es una comodidad para ti, y también es acceso para el agente.
  • La red no queda restringida. Nada en la configuración del Dev Container limita el tráfico saliente. El sandbox de terminal de VS Code tiene controles propios para eso, como chat.agent.sandbox.allowNetwork y una lista de dominios permitidos. Son capas distintas, y puedes usar ambas.

Mi recomendación para equipos: que el Dev Container sea el lugar por defecto donde corren los agentes, porque la reproducibilidad por sí sola lo justifica. Haz commit antes de cada sesión del agente y trata el aislamiento del contenedor como una capa, no como todo el modelo de seguridad. Desarrollamos el patrón general en Los agentes de código necesitan sandboxing — no solo buenos prompts y en Containment-First Agents, y cubrimos la apuesta de Microsoft por aislar agentes a nivel de sistema operativo en El Sandbox de Microsoft para Agentes de IA Llega al Kernel.

¿Qué más trae VS Code 1.138 para agentes y Codex?

  • Codex en VS Code, ampliado. Codex en el Agent Host ahora puede usar una suscripción de GitHub Copilot o de ChatGPT, y puedes cambiar de modelo entre ambas sin perder la conversación. Las sesiones pueden pasar de la app de ChatGPT a VS Code, y Codex puede usar las herramientas integradas, de extensiones y MCP de VS Code. Los ajustes son chat.agentHost.codexAgent.enabled y chat.editor.codex.preferAgentHost.
  • Pull requests desde sesiones de agente. Un solo formulario te permite editar el título y la descripción generados, marcar el PR como borrador y elegir opciones de merge. La opción Agent Merge es experimental y depende de chat.agentMerge.enabled.
  • Limpieza de sesiones (Preview). Las sesiones cuyos pull requests ya se fusionaron pueden marcarse como terminadas automáticamente y, si quieres, eliminarse tras un período de gracia. Viene desactivado por defecto.