El valor predeterminado sigue siendo tu cuenta de usuario
GitHub lanzó el sandbox local de Copilot con disponibilidad general el 7 de octubre de 2026 en Copilot CLI, la aplicación de Copilot y las sesiones de VS Code que usan Agent Host. El cambio importante no es que un agente pueda ejecutar comandos en local. Es que esos comandos ya pueden operar detrás de una política que limita lo que pueden leer, modificar y alcanzar.
La distinción importa porque la documentación del sandbox de GitHub indica que el sandbox local está desactivado por defecto. Sin él, los comandos de shell se ejecutan con el mismo acceso que la cuenta del desarrollador. Pueden alcanzar todas las rutas, redes y credenciales accesibles para el usuario autenticado.
Por tanto, un agente de programación con IA no queda contenido porque el producto ofrezca un sandbox. Queda contenido cuando la política efectiva está activada, puede aplicarse en ese equipo y es lo bastante estrecha para la tarea.
El límite tiene cuatro puertas
El lanzamiento expone controles para cuatro clases útiles de capacidad: rutas del sistema de archivos, destinos de red, credenciales y subprocesos.
Empieza por el sistema de archivos. Un agente suele necesitar lectura y escritura dentro de un working tree, lectura en la caché de paquetes y ningún acceso a datos ajenos del directorio personal. Eso debe ser una política de rutas, no una instrucción en el prompt. “No abras el archivo de credenciales” es una guía de comportamiento. Una ruta denegada es un límite de ejecución.
La política de red necesita el mismo tratamiento. Instalar dependencias puede exigir acceso a un registro de paquetes, mientras que una suite de pruebas quizá solo necesite localhost. Un permiso amplio de internet también ofrece a una herramienta comprometida o a una instrucción inyectada una ruta para enviar datos. Permite los hosts que el flujo realmente necesita y haz visible cualquier excepción cuando la tarea exceda esa lista.
Las credenciales son una decisión aparte. Las credenciales de Git y GitHub CLI pueden convertir una edición local en una escritura remota. La mayor parte de la generación y las pruebas de código no las necesitan. Déjalas fuera del sandbox hasta que un paso distinto y revisable requiera acceso autenticado.
Por último, decide qué ocurre con los servidores MCP locales y los language servers. GitHub documenta que los servicios locales compatibles pueden ejecutarse dentro del sandbox, mientras que los servidores MCP remotos nunca quedan contenidos por el límite de ejecución local. Un endpoint de herramientas en otro equipo necesita su propio modelo de autorización y aislamiento.
El modelo no es el límite de confianza. Estas cuatro políticas sí lo son.
La misma política usa mecanismos diferentes
El sandbox local de Copilot funciona con Microsoft eXecution Container, o MXC. MXC traduce una política común a controles del sistema operativo: Seatbelt en macOS, bubblewrap en Linux y mecanismos de contención compatibles en Windows.
La política común no vuelve idénticas las plataformas. GitHub describe el sandbox local como una contención ligera de procesos y archivos, no como una máquina virtual o un contenedor separado. También documenta diferencias de red según la plataforma. En macOS y Linux, las reglas de host pueden forzar el tráfico saliente a través de un proxy local. En Windows, esas reglas dependen de que los programas respeten la configuración del proxy, por lo que no ofrecen la misma protección frente a conexiones directas.
Trata el archivo de política como una intención portable y el backend seleccionado como el control real. Registra ambos en los diagnósticos. Una marca verde que solo diga “sandbox activado” es más débil que una prueba de que el host actual aplicó las rutas y reglas de red que el flujo necesita.
Fallar de forma cerrada cuando el límite es obligatorio
Los hosts no compatibles crean una decisión operativa. Copilot CLI puede conservar la preferencia guardada pero desactivar el sandbox durante la sesión actual cuando el host no lo admite. El usuario recibe un aviso, pero los comandos pueden ejecutarse sin el límite.
Para trabajos donde el sandbox sea un requisito, GitHub documenta ajustes gestionados que combinan sandbox.enabled con sandbox.failIfUnavailable. Esa pareja bloquea las solicitudes al modelo y la ejecución de herramientas cuando el entorno no puede aplicar la política.
Es la misma decisión que tomas con cualquier control de seguridad. Si el control es una comodidad opcional, un fallback visible puede ser aceptable. Si es la razón por la que el agente puede ejecutar comandos no confiables, volver a la cuenta del desarrollador invalida la aprobación.
Escribe el requisito en la política del proyecto o de la empresa. No dependas de que cada desarrollador detecte un aviso al inicio de una sesión larga.
Algunas operaciones quedan fuera del sandbox del sistema operativo
El límite también tiene una brecha de implementación explícita. GitHub indica que las herramientas de archivos integradas en el CLI se ejecutan dentro del proceso del propio CLI, así que el sandbox del sistema operativo no ve esas lecturas y escrituras. Las herramientas comprueban por sí mismas la política configurada de la mejor forma posible.
Eso es diferente de que el sistema operativo deniegue una operación de shell. No vuelve inútiles las herramientas integradas, pero cambia lo que puedes afirmar. Una prueba de política debe cubrir ambas rutas: pide a la herramienta integrada y a un comando de shell que lean un archivo denegado y confirma que ambos fallan.
El bypass por comando es otra apertura deliberada. Puede ser necesario para un compilador, un instalador o una operación de repositorio que no funciona con las restricciones actuales. Haz que los bypasses sean excepcionales, limitados y registrados. Un flujo que aprueba el mismo bypass amplio en cada ejecución ha descubierto una política incompleta, no una rutina aceptable.
Probar el límite efectivo
Antes de habilitar trabajo más autónomo, crea un repositorio pequeño para probar la política. Debe contener fixtures inofensivos que representen las capacidades que quieres proteger:
- Un archivo legible dentro del working tree.
- Un archivo denegado fuera de él.
- Un host de prueba permitido y otro bloqueado.
- Un comando que compruebe si existen credenciales de Git o GitHub.
- Un subproceso local y, si se usa, un servidor MCP.
Ejecuta las mismas comprobaciones en cada sistema operativo compatible. Registra la superficie de Copilot, el backend de MXC, la política efectiva y el resultado. Repite después de actualizar el IDE, el CLI o el sistema operativo. La prueba es pequeña porque la afirmación es pequeña: los comandos permitidos funcionan y los que quedan fuera del límite fallan.
Después mantén los efectos secundarios detrás de su propia aprobación. El sandbox reduce lo que un comando puede alcanzar. No decide si una migración de base de datos, la publicación de un paquete o un despliegue son correctos.
Qué no cambia
El sandbox local no vuelve confiable el código generado. La revisión, las pruebas y los controles de dependencias siguen aplicándose al resultado después de que salga de la sesión del agente.
Tampoco contiene servicios remotos. Un servidor MCP remoto, una API en la nube o un workflow del repositorio aplica sus propios permisos. La regla de red local puede bloquear una conexión, pero no puede reducir lo que una credencial remota aceptada tiene permitido hacer.
También sigue siendo necesario un working tree limpio y cambios recuperables. Un agente aún puede hacer una mala edición dentro de un directorio permitido. El control de versiones limita mejor el coste de ese error que una regla de sandbox más amplia.
El estándar práctico es concreto: activa el sandbox, deniega el acceso que la tarea no necesita, falla de forma cerrada cuando la aplicación sea obligatoria, prueba el backend efectivo y deja las escrituras remotas detrás de una puerta separada. La función aporta el límite. Tu política determina si ese límite significa algo.
Escrito por Dandelion Labs