GitHub Copilot ya no se limita a sugerir código: sus agentes pueden ejecutar comandos, modificar archivos y trabajar con herramientas. Eso hace que el aislamiento del entorno deje de ser un detalle técnico y pase a ser una medida de seguridad práctica. Desde septiembre de 2026, la aplicación de escritorio de GitHub Copilot incorpora sandboxing local en vista previa pública, con controles sobre archivos, red y credenciales.
En esta guía explicamos cómo configurar el sandbox local de GitHub Copilot para que un agente tenga el acceso mínimo necesario en cada proyecto, qué protege realmente, qué limitaciones tiene y cuándo conviene utilizarlo frente a un entorno aislado en la nube.
Qué es el sandbox local de GitHub Copilot
El sandbox local es una capa de aislamiento del sistema operativo que restringe lo que pueden hacer las herramientas ejecutadas por un agente de Copilot en tu ordenador. En lugar de permitir que un comando tenga automáticamente el mismo alcance que tu usuario, la sesión se ejecuta con una política que define qué rutas, redes y credenciales puede utilizar.
GitHub introdujo los sandboxes locales y cloud para Copilot en vista previa pública en junio de 2026 y amplió específicamente la configuración del sandbox en la aplicación de escritorio en septiembre. En la aplicación, la política se configura por proyecto y se aplica a las sesiones locales del repositorio y del árbol de trabajo.
La diferencia de seguridad es importante: sin sandbox, un comando lanzado por el agente puede tener, en términos generales, los permisos de tu propia cuenta. Con sandbox, el acceso efectivo queda limitado por la política configurada y por las restricciones que pueda imponer la organización.
Qué puede limitar el sandbox de Copilot
La configuración se divide en tres superficies principales:
- Sistema de archivos: puedes definir rutas adicionales con lectura y escritura, rutas adicionales de solo lectura y carpetas que deben quedar bloqueadas.
- Red: puedes controlar el acceso a Internet y a la red local según las necesidades del proyecto.
- Credenciales: puedes controlar el uso de credenciales de Git para operaciones HTTPS autenticadas y de GitHub CLI.
Esto no convierte al agente en una caja negra completamente desconectada. La idea es aplicar una política de mínimo privilegio: el agente conserva acceso a lo necesario para desarrollar, pero no debería recibir automáticamente acceso a todo lo que tu cuenta puede leer o modificar.
Cómo activar el sandbox local en GitHub Copilot app
1. Abre la configuración del proyecto
En la aplicación de GitHub Copilot, abre el proyecto en el que quieras trabajar y entra en sus ajustes. El sandbox local se configura por proyecto, por lo que activar la protección para un repositorio no cambia automáticamente la configuración de otros.
2. Activa “Sandbox new sessions”
Dentro de la sección Sandbox, activa la opción para iniciar nuevas sesiones con sandbox. La configuración afecta a las sesiones nuevas del proyecto; una sesión que ya estuviera ejecutándose no cambia de forma retroactiva simplemente por modificar el ajuste del proyecto.
GitHub también permite activar el aislamiento para una sesión local que ya está abierta mediante el comando /sandbox on. Las configuraciones de la aplicación Copilot y de Copilot CLI son independientes: activar una no modifica la otra.
3. Empieza por la política predeterminada
Para un proyecto normal, la recomendación más razonable es empezar con la política predeterminada y endurecerla cuando conozcas las necesidades reales del agente. GitHub señala que la política inicial está pensada para tareas habituales de desarrollo, como instalar dependencias, conectar con un servidor local, hacer push de una rama o crear una pull request.
No conviene bloquear indiscriminadamente toda la red o todas las credenciales si el flujo de trabajo necesita esos recursos. El objetivo es reducir superficie de ataque sin romper el proceso de desarrollo.
Cómo configurar los permisos de archivos
El control del sistema de archivos es probablemente la parte más importante para un ordenador personal. Un agente que modifica código necesita escribir en el repositorio, pero normalmente no necesita poder escribir en tu carpeta de documentos, directorios con claves privadas o configuraciones personales.
La configuración permite trabajar con listas de rutas adicionales con diferentes niveles de acceso. Una política prudente puede seguir esta lógica:
| Recurso | Política recomendada | Motivo |
|---|---|---|
| Repositorio activo | Lectura/escritura | El agente necesita editar y probar el código. |
| Documentación del proyecto fuera del repo | Solo lectura | Puede consultar contexto sin modificarlo. |
| Carpetas personales | Denegado | No aportan nada al desarrollo y contienen datos privados. |
| Claves SSH o secretos locales | Denegado cuando sea posible | Reduce el impacto de una instrucción o herramienta comprometida. |
Cómo controlar la red
El acceso de red merece una atención especial porque muchas tareas de desarrollo requieren Internet: instalar paquetes, consultar documentación, descargar dependencias o acceder a servicios de prueba. Sin embargo, una sesión que no necesita red puede funcionar con una política más restrictiva.
Si el proyecto trabaja con una API de pruebas, un servidor local o servicios internos, revisa primero qué conexiones necesita realmente. Después, aplica restricciones a todo lo demás cuando sea viable. Esto reduce la posibilidad de que una herramienta ejecutada por el agente utilice la red para acceder a recursos que no forman parte de la tarea.
La documentación de GitHub permite configurar el acceso de red y distingue entre las reglas de la política local y las restricciones que pueden venir impuestas por la organización.
Qué pasa con las credenciales de Git y GitHub CLI
Un sandbox no sirve de mucho si el agente puede utilizar sin restricciones todas las credenciales disponibles en el equipo. Por eso Copilot permite controlar el uso de credenciales para operaciones autenticadas.
En la configuración predeterminada, GitHub documenta que ciertas operaciones autenticadas de Git y GitHub CLI pueden seguir funcionando dentro del sandbox porque las credenciales necesarias se ponen a disposición de los comandos sandboxed. El usuario puede cambiar ese comportamiento desde la política de sandbox.
Para un proyecto personal sin necesidad de hacer push automático, una postura más conservadora es limitar las credenciales. Para un repositorio en el que el agente necesita crear ramas y pull requests, puede tener sentido mantenerlas disponibles, pero siempre dentro de una política explícita.
Sandbox local frente a worktree: no son lo mismo
GitHub Copilot app también utiliza worktrees para mantener separadas las sesiones de trabajo. Eso ayuda a evitar que dos tareas paralelas modifiquen el mismo árbol de trabajo, pero un worktree no es una frontera de seguridad.
Un worktree organiza archivos y ramas. El sandbox restringe lo que los comandos ejecutados por el agente pueden tocar fuera de ese contexto. GitHub explica expresamente que un árbol de trabajo separado no impide que un comando acceda a otras ubicaciones del equipo; el sandbox añade esa capa de protección.
Por eso, si ejecutas varios agentes en paralelo, una combinación de worktrees y sandbox es mucho más sólida que utilizar worktrees por sí solos.
Sandbox local frente a sandbox cloud de GitHub Copilot
| Característica | Sandbox local | Sandbox cloud |
|---|---|---|
| Dónde se ejecuta | En tu ordenador | En un entorno Linux aislado alojado por GitHub |
| Acceso a recursos locales | Sí, pero limitado por política | No depende de tu sistema local |
| Uso de recursos del PC | Sí | No |
| Continuidad entre dispositivos | Limitada al entorno local | Permite continuar sesiones remotas |
| Objetivo principal | Reducir el alcance de agentes en tu máquina | Aislar toda la ejecución fuera de tu equipo |
GitHub describe el sandbox cloud como un entorno Linux efímero y completamente aislado. Es especialmente interesante cuando quieres ejecutar tareas intensivas o mantener la sesión fuera de tu ordenador. El sandbox local, en cambio, tiene sentido cuando el agente necesita tus herramientas locales, servicios de desarrollo o el repositorio que ya tienes en el equipo.
Un ajuste importante: el sandbox está desactivado por defecto
La protección no debe darse por supuesta. GitHub indica que el sandbox local de la aplicación está desactivado por defecto. Si no lo activas, los comandos ejecutados por el agente pueden operar con los permisos de tu cuenta de usuario, dentro de las capacidades normales de tu sistema.
Esto es especialmente relevante si utilizas agentes para tareas que implican instalar dependencias, ejecutar scripts, modificar configuraciones o navegar por herramientas externas. El hecho de que una orden provenga de un agente de IA no significa que sea segura por definición.
En ese contexto, conviene combinar el sandbox con otras medidas: repositorios separados para pruebas, credenciales con el menor alcance posible, revisión de cambios antes del merge y protección de secretos.
Qué hacer si una herramienta necesita más permisos
Una política demasiado restrictiva puede impedir una tarea legítima. GitHub contempla este caso mediante el mecanismo de bypass: si un comando no puede ejecutarse dentro del sandbox, la aplicación puede solicitar autorización para ejecutarlo fuera de él, según la política efectiva.
El bypass debe tratarse como una excepción, no como la configuración habitual. Antes de aprobarlo, revisa qué comando se va a ejecutar, qué archivos necesita y por qué la tarea no puede realizarse dentro del entorno restringido.
Si una organización desactiva el bypass mediante políticas administradas, el agente debe detenerse cuando no pueda realizar una operación dentro del sandbox. Esa diferencia es importante en equipos donde la seguridad debe prevalecer sobre la comodidad.
Limitaciones que debes conocer antes de activarlo
- Es una vista previa pública: GitHub puede cambiar el comportamiento y la configuración.
- No todas las plataformas tienen exactamente las mismas capacidades: la documentación actual mantiene requisitos y diferencias por sistema operativo.
- Windows tiene requisitos específicos: GitHub indica que el sandbox local requiere actualmente una compilación Windows Insider para ese escenario.
- La aplicación y Copilot CLI tienen configuraciones separadas: no asumas que una política protege automáticamente ambas superficies.
- Una política administrada puede imponerse sobre la configuración del usuario: en entornos empresariales, las opciones bloqueadas por la organización tienen prioridad.
Por qué el sandbox importa especialmente con agentes de IA
La seguridad cambia cuando una IA puede actuar. Un chatbot que solo devuelve texto tiene un radio de acción limitado. Un agente que puede leer archivos, ejecutar comandos, conectarse a servicios y modificar un repositorio tiene un conjunto de capacidades mucho mayor.
Por eso el aislamiento debe considerarse parte de la arquitectura del agente y no un simple ajuste de comodidad. En Bitzeta ya hemos explicado los riesgos de los agentes con acceso a sistemas internos y las técnicas de prompt injection en navegadores con IA. El sandbox no elimina esos riesgos, pero puede reducir el impacto de una instrucción maliciosa, una herramienta comprometida o una decisión incorrecta del agente.
También puedes consultar nuestra guía sobre agentes de IA para entender cómo funcionan sus permisos, herramientas y ciclos de ejecución.
Configuración recomendada para un proyecto personal
- Activa el sandbox para las nuevas sesiones del proyecto.
- Mantén escritura solo en el repositorio que el agente necesita modificar.
- Deja como solo lectura cualquier carpeta adicional que solo aporte documentación.
- Bloquea carpetas personales y ubicaciones que contengan secretos.
- Limita la red cuando el proyecto no necesite acceso amplio a Internet o a la red local.
- Revisa si el agente necesita realmente credenciales de Git o GitHub CLI.
- Evita aprobar bypasses sin revisar primero el comando exacto.
- Comprueba la política efectiva antes de ejecutar tareas sensibles.
Preguntas frecuentes
¿El sandbox de GitHub Copilot está activado por defecto?
No. En la aplicación GitHub Copilot, el sandbox local está desactivado por defecto y debe activarse para las nuevas sesiones del proyecto.
¿El sandbox protege todo el ordenador?
No de forma absoluta. Su función es restringir los recursos que las herramientas ejecutadas por el agente pueden utilizar según la política configurada. Sigue siendo necesario revisar permisos, credenciales, dependencias y cambios producidos por el agente.
¿Un worktree sustituye al sandbox?
No. Un worktree separa el trabajo de distintas sesiones, mientras que el sandbox limita el alcance de los comandos y herramientas que ejecuta el agente. Son controles diferentes y complementarios.
¿Puedo usar sandbox local en Copilot CLI y en la aplicación?
Sí, pero las configuraciones son independientes. Activar el sandbox en la aplicación no significa que la política de Copilot CLI quede configurada de la misma forma.
¿Qué pasa si el agente necesita ejecutar un comando que el sandbox bloquea?
Dependiendo de la política, Copilot puede solicitar autorización para ejecutarlo fuera del sandbox. Si el bypass está prohibido por la organización, la tarea se detendrá en lugar de ejecutarse sin aislamiento.
Conclusión
El sandbox local de GitHub Copilot es una de las funciones más relevantes para quienes están empezando a utilizar agentes que ejecutan comandos y modifican código de forma autónoma. Su valor no está en hacer que Copilot sea “seguro” por sí solo, sino en reducir el radio de acción de sus herramientas mediante una política concreta de archivos, red y credenciales.
Para un desarrollador individual, la configuración más equilibrada es activar el sandbox, mantener escritura únicamente donde sea necesaria y tratar las credenciales y el acceso de red como permisos explícitos. En equipos empresariales, las políticas administradas añaden una capa adicional de control.
Relacionado en BitZeta: la guía de BitZeta para usar IA para programar.
Fuente oficial: NIST sobre IA.
Deja una respuesta