El 23 de septiembre de 2026, GitHub añadió el sandbox local a la aplicación GitHub Copilot. La función ejecuta las herramientas invocadas por el agente dentro de un aislamiento del sistema operativo y permite limitar, por proyecto, el acceso a archivos, redes y credenciales. Está en versión preliminar pública, viene desactivada de forma predeterminada y se aplica a sesiones locales en el repositorio o en un working tree. No se aplica a sesiones de cloud sandbox ni a sesiones ejecutadas en un host remoto.
Para quien quiera habilitar y probar la función de forma segura, el punto principal es no tratar el interruptor del sandbox como un permiso único. Cada proyecto tiene su propia política. La política predeterminada sigue permitiendo varias tareas habituales de desarrollo, por lo que revisar carpetas, acceso a red y credenciales es una parte esencial de la configuración.
Cómo habilitar el sandbox local por proyecto
- Abre la configuración de la aplicación GitHub Copilot.
- Selecciona el proyecto que quieres configurar.
- En la sección Sandbox, activa Sandbox new sessions.
- Inicia una nueva sesión local en el repositorio o en un working tree para que se aplique la configuración predeterminada del proyecto.
Activarlo en la configuración del proyecto no cambia una sesión que ya está en ejecución. En una sesión local activa, puedes usar /sandbox on para activar el aislamiento de inmediato. Este comando crea una anulación para la sesión actual y no cambia el valor predeterminado de las demás sesiones del proyecto. Del mismo modo, /sandbox off desactiva el aislamiento para esa sesión cuando la política efectiva lo permite.
Si cambias las reglas de sistema de archivos, red o credenciales en la configuración del proyecto, la nueva política se usa en sesiones nuevas o después de reiniciar una sesión existente. GitHub documenta /restart-session como forma de reiniciar conservando el historial de la sesión.
Qué revisar antes de considerar aislado el proyecto
El sandbox local se configura en tres grupos principales de control. La tabla resume el comportamiento documentado y la decisión práctica que conviene revisar.
| Área | Comportamiento y controles | Qué revisar en el proyecto |
|---|---|---|
| Sistema de archivos | La sesión tiene acceso de lectura y escritura al workspace y al directorio de trabajo actual. Puedes añadir rutas extra de lectura/escritura, rutas de solo lectura y rutas denegadas. | Concede acceso adicional solo cuando sea necesario. Prefiere solo lectura para bibliotecas, datos o carpetas de referencia que no deban modificarse. Usa rutas denegadas para directorios sensibles situados cerca del proyecto. |
| Internet saliente | El acceso a internet está permitido de forma predeterminada y puede bloquearse. | Si la tarea no necesita instalar dependencias, llamar a APIs o acceder a servicios externos, considera desactivarlo para reducir los recursos disponibles para el agente. |
| Red local | El acceso a loopback y a la red local está permitido de forma predeterminada y puede bloquearse. | Mantenlo solo cuando la sesión deba conectarse a un servidor de desarrollo, una base de datos local u otro servicio de red privada. |
| Credenciales de Git | Las operaciones Git HTTPS autenticadas pueden usar credenciales dentro del sandbox, y ese acceso puede desactivarse. | Desactívalo si la sesión no necesita hacer push ni realizar otra operación autenticada. |
| Credenciales de GitHub CLI | La autenticación de GitHub CLI puede estar disponible dentro del sandbox, y ese acceso puede desactivarse. | Desactívalo cuando la sesión no necesite crear pull requests ni realizar otras acciones autenticadas mediante gh. |
Una regla de denegación más específica sigue denegada aunque una carpeta padre más amplia tenga acceso concedido. Esto permite proteger una subcarpeta sensible sin bloquear todo un directorio de desarrollo.
Checklist de menor privilegio para cada proyecto
- Carpetas: ¿el agente realmente necesita leer o escribir fuera del workspace?
- Solo lectura: ¿una ruta compartida puede consultarse sin permitir cambios?
- Rutas denegadas: ¿hay claves, copias de seguridad, datos personales, archivos de producción u otros directorios locales que deban quedar fuera de alcance?
- Internet: ¿la sesión necesita un registro de paquetes, una API o GitHub durante esta tarea?
- Red local: ¿necesita localhost u otro servicio de la LAN?
- Git: ¿hay un motivo para exponer credenciales Git autenticadas a los comandos ejecutados por el agente?
- GitHub CLI: ¿la tarea requiere autenticación de gh o puede terminar antes de ese paso?
- Política empresarial: ¿algún valor está administrado o es más restrictivo por una política de la empresa?
La política efectiva puede ser más restrictiva que la seleccionada en el proyecto cuando existen configuraciones administradas por la empresa. Por eso, la pantalla del proyecto representa la configuración local solicitada, mientras que el comportamiento real también puede depender de controles aplicados al entorno.
Cómo probar el aislamiento sin depender solo de la pantalla de configuración
Después de activar el sandbox, realiza las comprobaciones en una sesión nueva y en un proyecto no crítico. El objetivo es confirmar que lo permitido sigue funcionando y que lo bloqueado falla de forma predecible.
- Prueba el workspace permitido. Pide a la sesión que lea un archivo del proyecto y cree o modifique un archivo descartable dentro del workspace. Debería funcionar cuando el proyecto conserva el acceso predeterminado de lectura y escritura.
- Prueba una ruta denegada. Añade una carpeta de prueba a la lista Denied e intenta acceder a ella desde la sesión. El acceso debería ser rechazado. No uses una carpeta realmente sensible solo para demostrar que el bloqueo funciona.
- Prueba internet. Desactiva Outbound internet y ejecuta una tarea que dependa claramente de una conexión externa, como consultar un registro de paquetes o un endpoint de prueba. La operación debería fallar por falta de conectividad.
- Prueba la red local. Si el proyecto usa un servidor local, desactiva Local network y verifica que la sesión ya no pueda alcanzarlo. Restaura el permiso solo si el flujo normal lo necesita.
- Prueba las credenciales. Desactiva Git credentials y GitHub CLI credentials y usa una operación que requiera autenticación en un repositorio o entorno de prueba. Las acciones que dependan de esas credenciales deberían dejar de funcionar dentro del sandbox.
- Restaura solo lo necesario. Después de las pruebas, vuelve a la política mínima que cubre el trabajo real del proyecto.
Hay una limitación importante en Linux: la documentación de la aplicación indica que el sandbox no puede controlar de forma independiente el acceso a la red local para algunos procesos iniciados, como comandos de shell y servidores MCP o LSP locales. La configuración sigue aplicándose a operaciones ejecutadas en el propio proceso, incluidas ciertas solicitudes web y conexiones MCP remotas. Por eso, las pruebas de red local deben tener en cuenta la plataforma.
Qué ocurre cuando la política solicitada no puede aplicarse
La aplicación acepta la configuración del sandbox antes de comprobar si el sistema operativo puede imponer todas las reglas. La verificación se realiza cuando se inicia el primer shell aislado. Si el host no puede aplicar la política solicitada, el shell falla con un mensaje de plataforma o política no compatible. Según GitHub, no continúa ejecutando el comando sin sandbox como alternativa silenciosa.
Este comportamiento es importante para la revisión de seguridad: un error del sandbox debe tratarse como un fallo de ejecución que hay que investigar, no como señal de que el agente completó la tarea con aislamiento parcial.
Cuando la aplicación pide ejecutar fuera del sandbox
Una herramienta puede necesitar un recurso bloqueado por la política. En ese caso, la aplicación GitHub Copilot puede mostrar una solicitud para ejecutar fuera del sandbox. Según la política efectiva, el usuario puede cancelar, ejecutar esa operación una vez fuera del aislamiento o desactivar el sandbox durante el resto de la sesión actual.
Ejecutar fuera del sandbox amplía el acceso de esa operación y debe ser una decisión consciente. En entornos empresariales, un administrador puede impedir este tipo de bypass. Desactivar temporalmente el sandbox desde esta solicitud no cambia el valor predeterminado del proyecto y termina cuando la sesión se reinicia o se vuelve a adjuntar.
El sandbox local no es lo mismo que un working tree ni que un cloud sandbox
Un working tree separa ramas y archivos de sesiones simultáneas, pero por sí solo no restringe lo que un comando puede alcanzar en otras partes del equipo. El sandbox local añade esa capa de contención para las herramientas ejecutadas por el agente.
Un cloud sandbox, en cambio, ejecuta la sesión en un entorno aislado alojado por GitHub. El sandbox local sigue ejecutándose en tu equipo, con controles del sistema operativo sobre archivos, redes y credenciales. Elegir entre una sesión local y una sesión en la nube es, por tanto, una decisión diferente de ajustar los permisos de un proyecto local.
La configuración del sandbox en la aplicación GitHub Copilot y en Copilot CLI también se gestiona por separado. Activar o restringir el aislamiento en una superficie no copia automáticamente la configuración a la otra.
Una configuración práctica para empezar
Para un proyecto común, una secuencia prudente es habilitar el sandbox para sesiones nuevas, mantener el acceso de lectura y escritura limitado al workspace cuando sea posible, denegar directorios locales sensibles, desactivar credenciales que no se vayan a usar y revisar si realmente se necesitan internet y la red local. Después, prueba esas restricciones en una sesión nueva y documenta las excepciones que el proyecto necesite.
El sandbox reduce el alcance de comandos no deseados. No elimina la necesidad de revisar las acciones del agente, especialmente cuando la aplicación solicita ejecutar fuera del aislamiento o cuando el proyecto necesita acceso amplio a redes, credenciales y rutas adicionales.
