GitHub Copilot ya tiene sandboxes locales y en la nube: que cambia de verdad para agentes que tocan codigo
GitHub anuncio el 2 de junio de 2026 que Copilot puede ejecutar trabajo agentic dentro de sandboxes locales y cloud. La mejora no es cosmetica: pone aislamiento, reanudacion y politicas alrededor de comandos, archivos y red.
GitHub movió una pieza importante el 2 de junio de 2026: Copilot ya puede correr dentro de sandboxes locales y también en sandboxes cloud. Si lo lees rápido parece otra mejora de seguridad. Si lo lees como builder, la historia real es otra: GitHub por fin está separando el agente de tu máquina y del repo con una capa operativa explícita.
Eso importa porque el coding agent dejó de ser un autocomplete con esteroides. Ahora ejecuta comandos, modifica archivos, consulta red y encadena pasos. En ese contexto, pedirle a un agente que “trabaje” sin una capa de aislamiento era sostenible para demos, no para equipos.
La decisión práctica: local o cloud
La documentación oficial deja muy clara la división:
- sandbox local para dejar que Copilot trabaje en tu equipo con acceso restringido a filesystem, red y capacidades del sistema;
- sandbox cloud para mover la sesión a un entorno Linux efímero hospedado por GitHub;
- y una política compartida de gobernanza para que no tengas que inventar un modelo distinto por cada superficie.
Ese matiz es clave. GitHub no está diciendo solo “aquí tienes una VM”. Está diciendo: elige dónde quieres que viva la ejecución del agente según riesgo, costo y comodidad.
Lo mejor del sandbox local no es la comodidad
En local, la activación pasa por /sandbox enable. Desde ese momento, los comandos que Copilot ejecuta en tu nombre corren dentro del sandbox y no con acceso pleno a tu sistema.
Para equipos chicos eso ya resuelve una tensión vieja: querías usar agente dentro del terminal, pero sin abrir filesystem y red “a ciegas”. GitHub también documenta soporte en macOS, Linux y Windows, además de enforcement centralizado con MDM para empresas.
Mi lectura aquí es simple: el sandbox local no existe para que te sientas más cómodo. Existe para que el agente pueda trabajar en un entorno útil sin heredar automáticamente todos tus privilegios.
Donde el sandbox cloud sí cambia el juego
La parte más potente está en cloud. GitHub documenta que copilot --cloud levanta una sesión interactiva en un entorno Linux efímero, aislado de tu equipo y de otras sesiones. También dice que el estado puede guardarse y retomarse después.
Eso abre tres casos de uso bastante concretos:
- trabajo pesado fuera de tu laptop: builds, pruebas largas o exploraciones paralelas sin comerse tus recursos locales;
- continuidad real: parar una sesión, guardar snapshot y retomarla después sin reconstruir todo;
- movilidad: seguir la misma sesión desde otro dispositivo.
Esa combinación se parece mucho más a una capa de runtime que a un simple terminal remoto.
El detalle que más me importa: gobernanza unificada
GitHub dice que las políticas del sandbox cloud comparten configuración con Copilot cloud agent. Esto es mejor de lo que parece.
En la práctica, muchas adopciones fallan porque cada nueva superficie del agente inventa permisos, controles y excepciones distintas. Cuando la gobernanza se fragmenta, los equipos terminan usando la ruta menos segura solo porque es la menos molesta.
Si GitHub logra que CLI, app y cloud agent compartan controles, el agente deja de ser una colección de features y empieza a parecerse a una plataforma.
También hay tradeoffs y sí conviene mirarlos antes
La documentación también deja los costos sobre la mesa:
- sandbox local no tiene costo extra sobre la seat de Copilot;
- sandbox cloud sí cobra por compute, memoria y storage del snapshot;
- y además la organización tiene que habilitar la policy correspondiente.
Entonces no es una decisión puramente técnica. También es una decisión de operación.
Yo no movería todo a cloud por reflejo. Si el trabajo es corto, sensible al contexto local o depende de herramientas ya instaladas, el sandbox local puede bastar. Si necesitas sesiones largas, reanudación y paralelismo, el sandbox cloud empieza a tener mucho más sentido.
Preguntas que sí deberías hacerte antes de activarlo
En vez de preguntar “¿está bueno?”, yo preguntaría:
- ¿qué tareas quiero que el agente ejecute sin tocar mi entorno real?
- ¿qué trabajos necesito retomar después sin reconstrucción manual?
- ¿cuánto me cuesta hoy el tiempo perdido en aprobaciones, miedo o cleanup?
- ¿qué parte de mi equipo necesita portabilidad entre dispositivos?
Si esas preguntas aparecen seguido, esta release sí tiene peso.
También conversa muy bien con nuestra nota sobre GitHub Copilot SDK en GA, porque una cosa abre el runtime programable y la otra le pone una superficie de ejecución más gobernable.
La lectura corta es esta: GitHub ya no está vendiendo solo un agente que escribe código; está vendiendo dónde y cómo debería correr ese agente. Y para equipos serios, esa diferencia vale más que otra mejora de UX.