Sandbox local de GitHub Copilot: cómo activarlo en la CLI, la app y VS Code (y qué no bloquea)

El sandbox local de GitHub Copilot ya está disponible de forma general en Copilot CLI, la app de Copilot y VS Code: limita qué archivos, redes y credenciales pueden usar los comandos que el agente ejecuta en tu máquina. GitHub lo anunció el 7 de octubre de 2026. Viene incluido en la licencia de Copilot sin costo adicional y está desactivado por defecto, así que nada cambia hasta que lo enciendes.

La función no es nueva: entró en vista previa pública el 2 de junio, y en yoDEV ya escribimos sobre por qué los sandboxes son la pieza que faltaba para dejar correr agentes de verdad y sobre la tecnología de Microsoft que hay debajo. Lo nuevo es que ahora es GA, está documentado y funciona igual en tres superficies. Este artículo es la mitad práctica: cómo activarlo, cómo ver qué bloquea, cómo abrirlo sin tirarlo a la basura y de qué no te protege.

¿Qué es un sandbox y qué es el sandbox local de GitHub Copilot?

Un sandbox es un entorno aislado donde un programa se ejecuta con acceso limitado al resto del sistema: solo puede leer, escribir y conectarse a lo que la política le permite. El sandbox local de GitHub Copilot (local sandboxing en la documentación en inglés) aplica esa idea a los comandos y herramientas que Copilot ejecuta por ti: comandos de shell, búsqueda de archivos y, por defecto, los servidores MCP y de lenguaje (LSP) locales. Sin él, esos comandos corren con todos los privilegios de tu usuario: pueden leer, escribir y borrar todo lo que tú puedes, llegar a cualquier red que alcance tu máquina y usar tus credenciales sin restricciones.

Debajo está Microsoft eXecution Container (MXC). Copilot declara una sandbox policy —qué rutas se pueden leer o escribir, si hay acceso a red, etcétera— y MXC la traduce al mecanismo de aislamiento nativo de cada sistema operativo:

  • macOS: Seatbelt
  • Linux: bubblewrap (bwrap)
  • Windows: el nivel BaseContainer del backend ProcessContainer, en versiones recientes de Windows 11

GitHub también ofrece sandboxes en la nube, que son otro producto: toda la sesión corre en un entorno Linux efímero alojado por GitHub, construido sobre Azure Container Apps Sandboxes. Al momento de publicar esta nota, los sandboxes en la nube estaban en vista previa pública y requerían una opción experimental.

¿Cuánto cuesta? ¿El sandbox de GitHub Copilot es gratis?

El sandbox local sí: la documentación de GitHub indica que está incluido en la licencia estándar de Copilot sin costo adicional. Al momento de publicar esta nota, ni el changelog ni la documentación detallaban qué planes individuales cubre.

Los sandboxes en la nube se cobran por uso, con tres medidores:

Medidor Unidad Precio (USD)
Cómputo segundo de cómputo $0.000024
Memoria GiB por segundo $0.000003
Almacenamiento (snapshots de sesiones detenidas) GiB por mes $0.005

En organizaciones, los sandboxes en la nube vienen desactivados: un administrador debe activar la política Cloud Sandbox access antes de que los miembros puedan usarlos.

¿Funciona en Windows 11, macOS y Linux?

Sí, pero los requisitos cambian según el sistema operativo y, ligeramente, según la superficie. Estos eran los requisitos al momento de publicar:

Copilot CLI y la app de Copilot

  • macOS: se recomienda macOS 15 (Sequoia) o posterior. Las versiones anteriores no se bloquean, pero no están probadas.
  • Linux: bubblewrap 0.5.0 o posterior y slirp4netns en tu PATH. Si la política permite tráfico saliente, la documentación también exige unshare/nsenter de util-linux 2.35+, iptables con el backend nf_tables y acceso a /dev/net/tun.
  • Windows: Windows 11 25H2 con KB5124010 o posterior, o 26H1 con KB5124006 o posterior.

VS Code (Agent Host)

  • macOS: sin requisitos adicionales.
  • Linux y WSL2: bubblewrap y socat (sudo apt-get install bubblewrap socat en Debian/Ubuntu). WSL 1 no es compatible.
  • Windows: la actualización de seguridad del 8 de septiembre de 2026 (KB5124008 para 24H2/25H2, KB5124012 para 26H1). Al momento de publicar, VS Code marcaba el soporte en Windows como experimental.

Ojo: si buscas “sandbox Windows 11”, es probable que encuentres Windows Sandbox, la máquina virtual desechable de Windows. Es otra cosa; el sandbox de Copilot no usa una VM.

Si tu máquina no puede aplicar la política pedida, el sandbox falla de forma cerrada: el comando da error en vez de ejecutarse sin protección. En la CLI, una preferencia guardada se desactiva para esa sesión con un aviso, y /sandbox enable se rechaza.

¿Cómo se activa el sandbox en Copilot CLI?

Dentro de una sesión de Copilot CLI, ejecuta:

/sandbox enable

El sandbox se aplica de inmediato a esa sesión y sigue activo en las siguientes sesiones interactivas y programáticas hasta que ejecutes /sandbox disable. La elección se guarda como sandbox.enabled en ~/.copilot/settings.json. Las sesiones que ya tenías abiertas en otras terminales no lo toman hasta que las reinicies (por ejemplo, con copilot --continue) o ejecutes /sandbox enable en ellas.

Los comandos disponibles:

Comando Qué hace
/sandbox status Indica si esta sesión realmente está en el sandbox
/sandbox policy [COMANDO] Muestra las rutas, la red y las capacidades efectivas, opcionalmente para un comando, sin ejecutarlo
/sandbox o /sandbox config Abre la configuración interactiva (pestañas General, Credentials, Filesystem, Network)
/sandbox enable / /sandbox disable Lo activa o lo desactiva

Para una sola sesión, sin tocar tu preferencia guardada, usa --sandbox (o --no-sandbox). También funciona en modo programático:

copilot --sandbox -p "PROMPT"

Cuando está activo, la línea de estado muestra sandbox enabled.

¿Cómo se activa en la app de Copilot?

Para la sesión actual:

/sandbox on

y /sandbox off para desactivarlo. Para que sea el comportamiento por defecto de un proyecto, abre Settings en la barra lateral, elige el proyecto en “Projects” y, en “Sandbox”, activa Sandbox new sessions. A diferencia de la CLI, /sandbox sin argumentos no abre ninguna pantalla de configuración. Los cambios de política se aplican a sesiones nuevas; para aplicarlos a una sesión abierta sin perder el historial, usa /restart-session.

¿Cómo se activa en VS Code?

En la configuración de la máquina donde corre el agente:

{
  "chat.agent.sandbox.enabled": "on"
}

Después, inicia una nueva sesión de Agent Host. Para cambiarlo solo en la sesión actual, abre Permissions y elige Sandboxing for terminal. Esto aplica únicamente a sesiones de Agent Host; el harness Local heredado y las implementaciones de terminal personalizadas no usan esta configuración de la misma forma.

Un detalle importante en VS Code: el sandbox es independiente del nivel de permisos. Aunque elijas Allow all, sigue restringiendo los procesos.

¿Qué permite el sandbox por defecto?

En Copilot CLI, la política por defecto está pensada para que el trabajo normal de desarrollo siga funcionando:

  • Sistema de archivos: lectura y escritura en tu directorio de trabajo, en las carpetas temporales y en el .git del repositorio; solo lectura en el resto del repositorio por encima de tu directorio de trabajo; lectura en ciertas ubicaciones del sistema y de herramientas de desarrollo, y escritura en algunas cachés de compilación y de paquetes. No incluye tu carpeta personal completa.
  • Red: internet saliente activado, red local desactivada. En la app de Copilot, ambas opciones de red vienen activadas.
  • Credenciales: Git y gh funcionan, pero los comandos dentro del sandbox solo ven valores de reemplazo. Un proxy local los cambia por las credenciales reales únicamente para destinos HTTPS aprobados: el host original en el caso de Git, y github.com, api.github.com y uploads.github.com en el caso de gh.

La opción Allow dev tool access, activada por defecto, merece una segunda mirada. Da acceso de lectura a la configuración y las cachés de herramientas de desarrollo, incluidos los registros de paquetes y los tokens que guardan. Es lo que permite que npm install funcione dentro del sandbox, y es lo primero que conviene desactivar si quieres una política estricta y estás dispuesto a conceder rutas a mano.

¿Cómo ver qué va a bloquear el sandbox antes de que lo bloquee?

Usa /sandbox policy seguido del comando que vas a ejecutar:

/sandbox policy npm install

Muestra las rutas y la configuración de red que recibiría ese comando, sin ejecutarlo, y en Notes indica cualquier ajuste que no se pudo aplicar. Cuando algo falla, el orden que recomienda GitHub es: /sandbox status, luego /sandbox policy y, por último, conceder solo la ruta o el host concreto en /sandbox config. Agregar un directorio con /add-dir no le da acceso dentro del sandbox.

Hay una trampa poco evidente: si bloqueas una ruta que todavía no existe —por ejemplo, un .env que piensas crear después—, Copilot CLI crea un directorio con ese nombre antes de ejecutar el comando. Si lo que querías bloquear era un archivo, créalo primero.

En VS Code, /sandbox policy genera un informe sandbox-policy.md de la sesión.

¿Cómo abrir el sandbox sin desactivarlo?

Concede exactamente lo que la tarea necesita, en lugar de desactivar el sandbox o aprobar una excepción para toda la sesión.

Sistema de archivos: en /sandbox config → Filesystem → User-configured paths, presiona A, escribe una ruta absoluta y elige Read/Write, Read-Only o Denied. En VS Code, el equivalente es:

{
  "chat.agent.sandbox.fileSystem.userConfiguredPaths": {
    "readwritePaths": ["/path/to/build-output"],
    "readonlyPaths": ["/path/to/shared-source"],
    "deniedPaths": ["/path/to/sensitive-data"]
  }
}

Red: las reglas por host están en Network → Proxy and blocking → Host rules. Tres reglas que conviene conocer antes de agregar ninguna: Deny siempre gana sobre Allow; un dominio denegado también bloquea sus subdominios; y en cuanto agregas una sola regla Allow, la lista se convierte en una lista blanca: todo host que no hayas permitido queda bloqueado.

Tokens de API: puedes enmascarar variables de entorno adicionales para que las herramientas dentro del sandbox solo vean un valor de reemplazo, y el proxy inyecte el valor real únicamente en los hosts que indiques:

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "envVars": {
        "EXAMPLE_API_TOKEN": {
          "injectHosts": ["api.example.com"]
        }
      }
    }
  }
}

El enmascaramiento solo funciona si la herramienta envía el valor en una cabecera HTTPS, como Authorization o X-Api-Key, o como contraseña en autenticación Basic. No funciona con HTTP sin cifrar, cuerpos de solicitud, URLs ni solicitudes firmadas.

Sobre las excepciones (bypass): cuando un comando queda bloqueado, Copilot puede ofrecer reintentarlo fuera del sandbox, y esa opción viene activada por defecto. Una excepción aprobada también se salta el enmascaramiento de credenciales: ese comando corre con tus secretos reales en su entorno. Apruébalas una por una, y solo cuando entiendas qué va a hacer el comando.

¿De qué no te protege el sandbox local?

Esta es la sección que conviene leer antes de decirle a tu equipo de seguridad “nuestros agentes corren en un sandbox”. El sandbox local es una barrera real y útil, pero acotada, y tanto GitHub como Microsoft son explícitos sobre sus límites:

  • No es una máquina virtual ni un contenedor. La documentación de GitHub lo ubica en el extremo ligero del espectro de aislamiento: restringe lo que un proceso puede leer, escribir y alcanzar, pero el comando sigue corriendo en tu máquina, con tu cuenta. La documentación de VS Code añade que no reemplaza la seguridad del endpoint.
  • MXC todavía se presenta como vista previa temprana. Al momento de publicar esta nota, el README del repositorio microsoft/mxc advertía que ningún perfil de MXC debe tratarse todavía como un límite de seguridad, y que algunas políticas generadas son conocidamente demasiado permisivas. La integración en Copilot es GA; el proyecto que hay debajo aún no retira esa advertencia.
  • En Windows, las reglas de red dependen de que el programa coopere. En macOS y Linux, el sandbox obliga a que toda conexión pase por el proxy local. En Windows depende de que los programas respeten la configuración de proxy, así que uno que la ignore puede conectarse directamente y saltarse tus reglas de host.
  • Las herramientas de archivos integradas de la CLI no están aisladas por el sistema operativo. Corren dentro del proceso de la CLI, que no está en el sandbox, y verifican la política por su cuenta en la medida de lo posible.
  • Los servidores MCP remotos nunca pasan por el sandbox. Solo los locales.
  • Los valores por defecto priorizan la productividad: internet saliente activado, acceso a herramientas de desarrollo (incluidos los tokens de registros) activado y solicitudes de excepción activadas.

Nada de esto es un argumento para no activarlo. Pasar de “el agente tiene todo lo que tengo yo” a “el agente tiene el directorio de trabajo y una lista de excepciones auditada” reduce mucho la exposición. Es un argumento para describirlo con precisión y para decidir qué valores por defecto ajustar.

Si necesitas un aislamiento más fuerte, rodea el trabajo con una barrera de contenedor o VM: un sandbox en la nube, o Dev Containers con agentes de IA en VS Code.

¿Cómo obligar a todo el equipo a usar el sandbox?

Con los enterprise managed settings, gestionados desde el servidor, por MDM o mediante archivo. Los valores gestionados aparecen como (managed) en /sandbox y el desarrollador no puede cambiarlos. Tres claves definen la postura:

  • sandbox.enabled: exige el sandbox.
  • sandbox.failIfUnavailable: combinado con sandbox.enabled, hace que la CLI bloquee las solicitudes al modelo y la ejecución de herramientas si la máquina no puede aplicar el sandbox, en vez de seguir sin él.
  • sandbox.allowBypass en false: sin excepciones por comando ni desactivación para la sesión.

Las reglas de host empresariales solo pueden reducir la lista blanca de un desarrollador, nunca ampliarla. En VS Code, los administradores deben usar los Copilot managed settings en lugar de las políticas de dispositivo heredadas; al momento de publicar, VS Code marcaba esa aplicación gestionada como vista previa.


¿Y tú? ¿Dejas que tus agentes de código ejecuten comandos en tu máquina sin supervisión, o apruebas cada uno?

¿Cómo ejecutan comandos tus agentes de código hoy?
  • Ya los corro dentro de un sandbox o contenedor
  • Apruebo los comandos uno por uno
  • Los dejo correr con los permisos de mi usuario
  • Prefiero otra opción (cuéntanos cuál)
0 votantes

Comenta abajo o, si este artículo te llegó por correo, responde directamente al email: tu respuesta se publica aquí.

Relacionado: Sandboxes para Copilot: la Pieza que Faltaba para Dejar Correr Agentes de Verdad