Desde el 7 de octubre de 2026, el sandbox local de GitHub Copilot deja atrás la vista previa pública en la que estaba desde junio y pasa a estar disponible para todos los suscriptores, en GitHub Copilot CLI, la aplicación GitHub Copilot y las sesiones de VS Code que usan Agent Host. La función limita lo que las herramientas y comandos lanzados por Copilot pueden leer, modificar o contactar en el equipo del desarrollador, según políticas definidas localmente o impuestas por la organización.
Qué cambia con la disponibilidad general
El principio no ha cambiado desde la vista previa: los comandos que ejecuta Copilot corren dentro de un límite de ejecución restringido, con acceso controlado al sistema de archivos, la red, las credenciales de Git y de GitHub CLI, y otras capacidades del sistema. El aislamiento también cubre herramientas y servicios locales, incluidos los servidores MCP y de lenguaje ejecutados en local cuando hay soporte. Está incluido en la suscripción de Copilot, sin coste adicional.
Microsoft eXecution Container, el mecanismo de fondo
El sandbox se apoya en Microsoft eXecution Container (MXC), un proyecto que traduce una política de sandbox común en controles nativos del sistema operativo, en Windows, macOS y Linux. Esta capa de abstracción permite a GitHub aplicar la misma política de seguridad sin importar la plataforma del desarrollador, en lugar de reescribir la lógica de aislamiento para cada sistema.
| Aspecto | Sandbox local | Sandbox en la nube |
|---|---|---|
| Estado a 7 de octubre de 2026 | Disponibilidad general | Vista previa pública desde junio de 2026 |
| Dónde se ejecuta | Equipo del desarrollador | Infraestructura de GitHub |
| Sistemas cubiertos | Windows, macOS, Linux vía MXC | Gestionado por GitHub |
| Coste | Incluido en la suscripción Copilot | Incluido durante la vista previa |
| Imponible por la empresa | Sí, mediante ajustes gestionados | Sí |
Configurar la política del sandbox
Los ajustes del sandbox local viven en settings.json, bajo la clave sandbox, dentro del directorio de configuración de Copilot CLI. El comando /sandbox abre una interfaz interactiva con tres pestañas (General, Sistema de archivos, Red), mientras que /sandbox policy muestra la política efectiva para el directorio actual: qué rutas son legibles, modificables o están bloqueadas, y el alcance del acceso a la red.
{
"sandbox": {
"filesystem": {
"includeWorkingDirectory": true
},
"auth": {
"git": "allow",
"gh": "allow"
},
"network": {
"default": "deny"
}
}
}Desde la versión 1.0.79 del CLI, las claves de autenticación cambiaron de nombre: sandbox.gitAuth y sandbox.ghAuth pasaron a ser sandbox.auth.git y sandbox.auth.gh, sin migración automática de los archivos de configuración antiguos.
Qué puede imponer la empresa
Los administradores de Copilot Enterprise y Business pueden hacer obligatorio el sandbox mediante ajustes gestionados e impedir que los desarrolladores debiliten esa política. El aislamiento se aplica a la ejecución de herramientas, no a la elección del modelo: una política de sandbox se mantiene sea cual sea el modelo que use Copilot para razonar.
El aislamiento no depende del modelo elegido: actúa sobre la ejecución de las herramientas, no sobre la inteligencia que las activa.
Activar un sandbox local o conectar un modelo local con /model no desactiva la telemetría de GitHub ni el acceso a la red de Copilot. Solo la variable COPILOT_OFFLINE=true impide que el CLI contacte con los servidores de GitHub.
Lo que hay que recordar
El sandbox local deja la vista previa y se convierte en el ajuste por defecto recomendado para cualquier flujo autónomo de Copilot, en las tres superficies principales de la herramienta. La política es gratuita, se apoya en MXC en los tres sistemas operativos y puede bloquearse a nivel de organización. Queda en manos de cada equipo definir qué rutas, qué red y qué credenciales necesitan realmente los agentes que dejan funcionar sin supervisión constante.
Recomiendo activar el sandbox local por defecto en todos los equipos que ejecuten agentes de Copilot en modo autónomo, incluso fuera de cualquier obligación empresarial: es la única forma de dejar que un agente itere sin supervisión constante sin darle acceso completo al sistema. Pasar a disponibilidad general no relaja la disciplina que sigue haciendo falta alrededor de los servidores MCP expuestos: un agente bien aislado sigue siendo un agente, no una garantía por sí solo — Simon Janvier.
Para profundizar: el anuncio oficial en el changelog de GitHub.
