Sandbox local de GitHub Copilot App: configuración y pruebas
Guía práctica sobre valores del proyecto, anulaciones de sesión, políticas de archivos, red y credenciales, fallo seguro y verificación.
Índice
Has activado el sandbox, pero la sesión que ya estaba abierta conserva los permisos anteriores, o el agente pide acceso una y otra vez para instalar dependencias, conectarse a un servidor local o enviar una rama. El problema suele estar en cómo se combinan el valor predeterminado del proyecto, la anulación de la sesión y los controles separados de archivos, red y credenciales.
Al terminar esta guía podrás elegir una política inicial para un repositorio local o un working tree, aplicar los cambios a la sesión correcta y comprobar los límites con datos ficticios. La ruta más corta es: confirmar el tipo de sesión → activar Sandbox new sessions → limitar las tres áreas → iniciar o reiniciar la sesión → ejecutar pruebas seguras.
GitHub anunció esta función el 23 de septiembre de 2026 y sigue en vista previa pública, por lo que la interfaz y el comportamiento pueden cambiar. Recuerda tres límites: el sandbox local viene desactivado, la política se configura por proyecto y, si el host no puede imponerla, el shell aislado falla en vez de ejecutar el comando sin protección de forma silenciosa.
Primero confirma que tu sesión está cubierta
Esta política del proyecto solo se aplica a sesiones de repositorio local y working tree local. Los sandboxes en la nube, hosts remotos y GitHub Copilot CLI siguen otros mecanismos, así que comprueba el alcance antes de cambiar ajustes que tu sesión objetivo no leerá.
| Tipo de sesión | ¿Se aplica? | Límite que debes recordar |
|---|---|---|
| Sesión de repositorio local | Sí | Usa la configuración de sandbox del proyecto actual |
| Sesión local de working tree | Sí | Un working tree separa ramas y archivos, pero no restringe el acceso a otras ubicaciones del equipo; el sandbox añade esa frontera |
| Sesión de sandbox en la nube | No | Utiliza su propio aislamiento en la nube |
| Sesión ejecutada en un host remoto | No | La política local del proyecto no se aplica al host remoto |
| GitHub Copilot CLI | Se configura aparte | Los ajustes de Copilot app y Copilot CLI no se sustituyen entre sí |
Las políticas administradas por la empresa pueden hacer que la política efectiva sea más restrictiva que la solicitada en el proyecto. Por eso, la página del proyecto describe lo que la aplicación pide, no necesariamente el acceso máximo que permitirá la organización.
Cómo activar el sandbox para sesiones nuevas
Para que las próximas sesiones locales usen la política del proyecto, activa Sandbox new sessions y crea una sesión nueva; cambiar el interruptor no actualiza una sesión que ya está abierta. Sigue estos pasos:
- Abre la configuración de GitHub Copilot app.
- Selecciona el proyecto que quieres configurar.
- Busca la sección
Sandbox. - Activa
Sandbox new sessions. - Inicia una nueva sesión local.
El interruptor solo afecta a las sesiones creadas después. No modifica una sesión que ya está en ejecución. Los cambios posteriores en archivos, red o credenciales también se aplican únicamente a sesiones nuevas o tras reiniciar una sesión.
Para conservar el historial de la conversación y volver a cargar la política, introduce /restart-session en la sesión existente.
GitHub recomienda comenzar con la política predeterminada en la mayoría de los proyectos. Permite tareas comunes como instalar dependencias, conectarse a un servidor de desarrollo local, enviar una rama y crear un pull request. Endurece la política cuando el proyecto esté junto a carpetas sensibles, no necesite red o no deba usar tus credenciales.
Cómo limitar por separado archivos, red y credenciales
Son tres controles independientes: restringir archivos no desactiva credenciales, y quitar credenciales no protege un directorio sensible que todavía se puede leer. Endurece cada área según la tarea en lugar de apagarlo todo de una vez.
1. Sistema de archivos: qué se puede leer y modificar
Empieza con el alcance mínimo: conserva lectura y escritura en el workspace y añade otras rutas solo cuando la tarea realmente las necesite. Por defecto, una sesión aislada puede leer y escribir en su workspace y directorio actual; la configuración añade tres listas:
Additional read/write: carpetas adicionales que las herramientas del agente pueden leer y modificar.Additional read-only: carpetas adicionales que pueden leer, pero no modificar.Denied: carpetas a las que no pueden acceder.
Una carpeta más específica incluida en Denied sigue prohibida aunque una carpeta superior más amplia tenga acceso de lectura o escritura. Es preferible conceder la ruta mínima necesaria en lugar de abrir todo el directorio personal y depender de muchas excepciones.
En Windows hay un límite de aplicación importante. Puedes guardar una ruta denegada, pero si las capacidades activas del sandbox de Windows no pueden garantizar la prohibición, el comando falla con un mensaje de tipo unsupported-policy. No continúa con la ruta expuesta ni desactiva el sandbox automáticamente.
2. Red: separa internet de la red local
Si la tarea instala dependencias o usa un servidor de desarrollo local, no cierres automáticamente las dos vías; decide por separado si necesita internet saliente y red local. Por defecto, la sesión puede alcanzar ambas y puedes controlar:
Outbound internet: acceso a GitHub, registros de paquetes y otros servicios de internet.Local network: conexiones loopback y de red local, incluidos servidores de desarrollo locales.
Las restricciones pueden afectar a la instalación de dependencias, llamadas API, servidores de vista previa y cualquier herramienta que necesite conexión. Trátalas como una decisión funcional, no como un interruptor de seguridad sin coste.
Linux tiene una limitación concreta: el sandbox no puede controlar de forma independiente el acceso a la red local de procesos generados, como comandos de shell y servidores MCP o LSP locales. El ajuste sí se aplica a operaciones dentro del proceso, como solicitudes web y conexiones MCP remotas. En Linux, verifica ambos caminos en lugar de probar solo uno.
3. Credenciales: controla Git y GitHub CLI por separado
Para revisar código o hacer análisis sin conexión, desactiva primero las credenciales de Git y GitHub CLI; actívalas solo si debes enviar una rama o crear un pull request. Por defecto, las operaciones autenticadas están disponibles y puedes desactivar:
Git credentials: operaciones Git HTTPS autenticadas.GitHub CLI credentials: autenticación utilizada por GitHub CLI.
Al desactivarlas, acciones como enviar una rama o crear un pull request pueden dejar de funcionar dentro del sandbox. La política de archivos y la de credenciales son fronteras diferentes: aunque desactives credenciales, protege con reglas de archivos los directorios que contienen claves, configuración u otros datos sensibles.
Cuándo cambiar el proyecto, la sesión actual o una sola operación
Cambia el proyecto cuando las sesiones futuras deban heredar la regla; usa /sandbox on o /sandbox off para la sesión actual; tras editar la política del proyecto, ejecuta /restart-session si la sesión activa debe recargarla.
| Acción | Cuándo entra en vigor | Efecto sobre otras sesiones |
|---|---|---|
Cambiar los ajustes Sandbox del proyecto | En sesiones nuevas o reiniciadas | Modifica el valor predeterminado heredado por sesiones posteriores del proyecto |
Introducir /sandbox on en una sesión local activa | De inmediato, como anulación persistente de esa sesión | No cambia el valor del proyecto para otras sesiones |
Introducir /sandbox off en una sesión local activa | Desactiva de inmediato el sandbox de esa sesión | No cambia otras sesiones; los comandos obtienen el mismo acceso a archivos, red y credenciales que tu cuenta de usuario |
Introducir /sandbox on o /sandbox off antes de iniciar una sesión | Cambia el valor del proyecto que heredarán las sesiones nuevas | Afecta a las sesiones iniciadas después con ese valor |
Introducir /restart-session | Reinicia la sesión actual, conserva el historial y recarga la política | No edita por sí mismo la política del proyecto |
Si una herramienta necesita acceso no permitido, la aplicación puede mostrar Run outside the sandbox?. Según la política efectiva, puedes cancelar, ejecutar esa operación una vez fuera del sandbox o desactivarlo durante el resto de la sesión. Un propietario de empresa puede impedir que los usuarios ejecuten herramientas fuera del sandbox.
Desactivarlo desde este aviso no reescribe el valor del proyecto ni la anulación existente de la sesión. El estado temporal termina cuando la sesión se reinicia o se vuelve a adjuntar. Tras aparecer Sandbox off for this session, Re-enable sandbox lo activa de nuevo.
El orden más seguro es cancelar primero y entender por qué el comando necesita más acceso. Si la necesidad es recurrente, ajusta de forma precisa la política y reinicia. Ejecuta una operación una sola vez fuera del sandbox únicamente tras revisar el comando, sus argumentos y su impacto. En un repositorio desconocido o con un comando construido dinámicamente desde un Prompt, evita desactivar todo el sandbox por comodidad.
Si el host no puede imponer la política, el comando se detiene
Si el sistema operativo no puede hacer cumplir una regla, el resultado seguro es que el comando falle, no que continúe automáticamente sin sandbox.
GitHub Copilot app acepta la configuración antes de saber si el sistema operativo puede aplicar todas las reglas. La compatibilidad se comprueba cuando se inicia el primer shell dentro del sandbox.
Si el host no puede aplicar la política solicitada:
- El shell muestra
unsupported-platformounsupported-policy. - El comando no continúa sin sandbox.
- Si la aplicación muestra
Sandbox unavailable, corrige el problema indicado y seleccionaRetry sandbox.
Es un comportamiento fail-closed, no una ejecución de mejor esfuerzo. Guardar los ajustes correctamente no demuestra que la política esté activa en el equipo. Inicia al menos un shell aislado, confirma que no aparece un mensaje de incompatibilidad y realiza una verificación mínima.
Cómo verificar la política con datos ficticios
GitHub describe el comportamiento que debería imponer la política, pero solo una prueba en tu equipo confirma que funciona con ese sistema operativo y esa combinación de reglas. El procedimiento usa carpetas desechables y archivos ficticios, sin tocar claves reales ni configuración de producción.
Crea carpetas de prueba desechables fuera del workspace y coloca solo archivos ficticios. No utilices claves SSH reales, credenciales de nube ni configuración de producción.
| Comprobación | Procedimiento seguro | Comportamiento esperado |
|---|---|---|
| Herencia de una sesión nueva | Activa Sandbox new sessions y crea una sesión local nueva | La nueva sesión usa la política; una antigua no cambia automáticamente |
| Aplicación de un cambio | Cambia una regla e introduce /restart-session | La sesión se reinicia, conserva el historial y recarga la política |
| Carpeta de solo lectura | Añade una carpeta desechable a Additional read-only, lee un archivo ficticio e intenta crear otro | La lectura debe funcionar y la modificación debe bloquearse |
| Carpeta denegada | Añade otra carpeta desechable a Denied e intenta listar o leer un archivo ficticio | El acceso debe bloquearse aunque una ruta superior esté permitida |
| Internet | Desactiva Outbound internet y realiza una comprobación de conexión sin efectos | La conexión externa debe fallar; vuelve a activarla y compara |
| Red local | Desactiva Local network y conecta con un servicio local desechable | El acceso debe seguir las capacidades de la plataforma; considera el límite de procesos generados en Linux |
| Credenciales Git | Desactiva Git credentials y ejecuta una comprobación autenticada que no modifique un repositorio de prueba | Las operaciones HTTPS autenticadas pueden no estar disponibles |
| Credenciales de GitHub CLI | Desactiva GitHub CLI credentials y ejecuta una comprobación no modificadora como gh auth status | GitHub CLI no debería recibir la capacidad de autenticación anterior; el error exacto puede variar |
| Fail-closed | Si aparece unsupported-platform o unsupported-policy, comprueba que no se creó el archivo ficticio de destino | El comando no debe continuar sin sandbox ni producir el efecto previsto |
Elimina las carpetas al terminar y restaura únicamente los permisos mínimos que necesita el proyecto. No demuestres una regla de denegación intentando abrir un directorio realmente sensible.
Qué política inicial conviene en cada escenario
El desarrollo diario, un repositorio desconocido y el análisis sin conexión no deberían compartir la misma política. Conserva lo necesario para el trabajo normal, empieza más estricto con código desconocido y desactiva primero red y credenciales en tareas offline.
Desarrollo cotidiano
Activa el sandbox, conserva las capacidades de red y credenciales predeterminadas, añade solo las carpetas externas necesarias y deniega explícitamente los directorios sensibles cercanos. Es adecuado para instalar dependencias, ejecutar servicios locales, enviar ramas y abrir pull requests.
Revisión de un repositorio desconocido
Concede lectura y escritura solo al workspace, monta material de referencia adicional como solo lectura, desactiva de forma predeterminada las credenciales de Git y GitHub CLI y mantén internet apagado hasta entender el origen de las dependencias. Si necesitas acceso temporal, abre una capacidad concreta en lugar de usar inmediatamente /sandbox off.
Análisis local sin conexión
Desactiva internet y las credenciales innecesarias, manteniendo solo el acceso imprescindible a archivos. Si también importa aislar la red local, verifica por separado los procesos generados en Linux; no supongas que un único interruptor controla todos los procesos de forma idéntica.
No son perfiles con nombre oficial de GitHub. Son puntos de partida construidos a partir de las dimensiones de permiso disponibles. Ajusta la política final al repositorio, sistema operativo, reglas empresariales y tarea real.
Errores que dejan la política sin efecto o demasiado abierta
Los errores más comunes son confundir “ajustes guardados” con “política aplicada” y desactivar todo el sandbox tras la primera denegación. Los siete casos siguientes falsean la prueba o conceden más acceso del necesario.
- Tratar un working tree como frontera de seguridad. Separa ramas y archivos concurrentes, pero no impide acceder a otras ubicaciones del equipo.
- Cambiar la política y seguir probando una sesión antigua. Los cambios no son retroactivos; crea otra sesión o usa
/restart-session. - Suponer que la app y la CLI comparten sandbox. Se configuran por separado.
- Tomar un guardado correcto como prueba de compatibilidad. La comprobación llega al iniciar el primer shell aislado.
- Olvidar qué implica
/sandbox off. Los comandos reciben el alcance de acceso de tu cuenta de usuario. - Suponer que la red se comporta igual en cada plataforma. Linux tiene una limitación documentada para la red local de procesos generados.
- Usar un bypass amplio ante cualquier denegación. Suele ser más seguro confirmar la necesidad, hacer el ajuste mínimo y reiniciar.
Qué hacer ahora
Primero confirma que usas una sesión de repositorio local o working tree local y activa Sandbox new sessions. Para desarrollo diario, parte de la política predeterminada y conserva solo los directorios, conexiones y credenciales que necesita la tarea; para código desconocido o análisis offline, empieza con el perfil más estricto y abre una capacidad cada vez.
Después de cambiar la política del proyecto, crea otra sesión o ejecuta /restart-session, y verifica con datos desechables los límites de solo lectura, denegación, red y credenciales. Si aparece unsupported-platform, unsupported-policy o Sandbox unavailable, resuelve la incompatibilidad en vez de usar /sandbox off y confundir un resultado sin aislamiento con una prueba correcta.
Referencias oficiales
Consulta estas páginas de GitHub antes y después de configurar para comprobar la interfaz, el alcance y el comportamiento de fallo actuales.
