Los permisos asistidos (assisted permissions) de GitHub Copilot CLI, la app de Copilot y VS Code hacen que un modelo revise cada solicitud del agente y apruebe solo las que considera seguras; el resto te las sigue preguntando a ti. Están disponibles de forma general desde el 26 de octubre.
https://github.blog/changelog/2026-10-26-github-copilot-assisted-permissions-generally-available/
Si usas el agente de Copilot a diario, conoces las dos opciones que había hasta ahora. La aprobación manual es segura, pero te interrumpe cada pocos segundos. El modo allow-all (--allow-all, --yolo) elimina las interrupciones y, con ellas, tu control sobre cada acción. Los permisos asistidos son la propuesta de GitHub para el término medio.
¿Qué son los permisos asistidos en GitHub Copilot?
Son un modo de permisos en el que un modelo, y no tú, toma la primera decisión sobre las solicitudes elegibles. Según la documentación de GitHub, hay tres tipos de solicitudes elegibles:
- ejecutar un comando
- acceder a una ruta del sistema de archivos
- abrir una URL
Para cada una, el modelo comprueba si la acción es segura y si está dentro de la autoridad que le diste a Copilot para la tarea. El resultado es uno de dos:
- Está seguro de que es segura: Copilot la aprueba y continúa sin preguntarte.
- No está seguro: Copilot te pregunta, exactamente como lo haría con aprobación manual.
Algunas cosas quedan fuera de la revisión. Las solicitudes que ya tenías permitidas se ejecutan sin preguntar y sin pasar por el modelo. Las reglas de denegación y las restricciones de la empresa siguen aplicándose. Las demás llamadas a herramientas que las reglas de la empresa obligan a aprobar, y las solicitudes para saltarse el sandbox local, no las revisa el modelo: siguen el flujo normal de permisos de la sesión. Si la revisión no está disponible o no puede evaluar una solicitud, esa solicitud también vuelve al flujo normal.
El modelo que hace la revisión no es necesariamente el mismo con el que estás conversando. Copilot elige el modelo revisor; si no está disponible, la revisión puede usar el modelo activo de tu sesión. Si usas tu propio proveedor de modelos, la revisión usa siempre el modelo activo de la sesión.
¿Permisos asistidos, aprobación manual o --yolo?
| Modo | Revisión por modelo | Cuándo te pregunta | Supervisión |
|---|---|---|---|
| Aprobación manual | No | En cada acción que no esté ya permitida (aprobación única o para toda la sesión) | Máxima |
| Permisos asistidos | Sí, en solicitudes elegibles | Solo cuando el modelo no está seguro | Menos interrupciones, sin permiso global |
Allow-all (--allow-all, --yolo, /permissions allow-all, /yolo) |
No | Nunca | Ninguna por acción |
La diferencia práctica: allow-all concede la confianza por adelantado para toda la sesión. Los permisos asistidos la conceden solicitud por solicitud, según un juicio sobre esa acción concreta.
¿Cómo se activan en Copilot CLI, la app y VS Code?
En Copilot CLI
Dentro de una sesión interactiva:
-
/permissions assistedlos activa solo para la sesión actual -
/permissions manualvuelve a la aprobación manual -
/permissions showmuestra el modo actual -
/permissionssin argumentos abre una lista para elegir
Para que sea el modo por defecto en todas las sesiones interactivas nuevas, añade esto a ~/.copilot/settings.json:
{
"defaultPermissionMode": "assisted"
}
Cámbialo a "manual" para volver atrás.
En ejecuciones no interactivas (scripts, CI), usa el flag o la variable de entorno:
copilot -p "Fix the failing tests" --assisted-approval
COPILOT_ASSISTED_APPROVAL=true
--assisted-approval es solo para ejecuciones no interactivas: si lo usas para iniciar una sesión interactiva, el comando termina con un error.
En la app de GitHub Copilot
Abre el menú de modo, elige Tool permissions y luego Assisted. Esto también lo guarda como predeterminado para las nuevas sesiones locales. Para cambiar solo la sesión actual, escribe /permissions assisted en el cuadro de prompt.
En VS Code
Selecciona Assisted permissions en el selector de permisos del chat. Según la documentación de VS Code, hay tres condiciones:
- La opción no está disponible en sesiones con el harness Local.
- Tienes que elegir aislamiento Folder: las sesiones en Worktree usan siempre Allow all.
- La primera vez que eliges este nivel, un diálogo de advertencia te pide confirmación.
El nivel con el que arrancan las sesiones nuevas se define con la configuración chat.permissions.default.
¿Qué pasa en modo autopilot y en CI?
En modo autopilot y en ejecuciones no interactivas no hay nadie a quien preguntar, así que las solicitudes que necesitarían tu aprobación se deniegan. La explicación del modelo vuelve a Copilot, para que el agente pruebe otro camino en lugar de quedarse bloqueado.
Para la automatización, esto es lo más importante: con permisos asistidos, una ejecución desatendida se cierra en negativo ante cualquier cosa sobre la que el modelo no esté seguro.
¿Cómo se bloquea --yolo para todo el equipo?
Aquí la función se convierte en una herramienta de gobernanza. Los administradores de una empresa pueden usar la configuración gestionada (enterprise-managed settings) para controlar qué modos pueden usar los desarrolladores:
-
permissions.disableBypassPermissionsMode: "disable"bloquea la aprobación incondicional (allow-all) sin desactivar los permisos asistidos -
permissions.disableAssistedPermissionsMode: truedesactiva los permisos asistidos -
permissions.defaultModedefine un modo predeterminado gestionado para las sesiones nuevas, que tiene prioridad sobre eldefaultPermissionModede cada desarrollador
Los desarrolladores pueden cambiar a cualquier otro modo que la política permita. Si el modo predeterminado configurado no está disponible o está prohibido, la sesión arranca con aprobación manual.
La primera opción es la interesante. Hasta ahora, un equipo que quería menos interrupciones tenía que tolerar que sus desarrolladores usaran --yolo. Ahora un administrador puede sacar --yolo de la mesa y dejar los permisos asistidos como la opción rápida.
¿Es seguro usarlo sin sandbox?
No por sí solo, y GitHub lo dice sin rodeos. Su documentación advierte que el modelo puede equivocarse y aprobar acciones peligrosas o no deseadas, y que la función no sustituye al sandboxing ni a las restricciones de acceso. Menos interrupciones no te quitan la responsabilidad sobre lo que hace Copilot.
Antes de meter esto en un pipeline, hay dos detalles de la CLI que conviene revisar:
-
Los flags no se anulan entre sí.
--assisted-approvalanula--allow-all-tools, pero--allow-all-pathsy--allow-all-urlssiguen aplicándose. Si combinas los permisos asistidos con--allow-allo--yolo, el acceso a rutas y URLs puede quedar sin restricciones. -
Puede fallar en silencio. Si los permisos asistidos no se pueden activar (por ejemplo, porque la configuración de la empresa los bloquea), la CLI escribe una advertencia en la salida de error estándar y cualquier
--allow-all-toolsque hayas pasado sigue aplicándose. En ejecuciones automatizadas, revisa stderr en busca de esa advertencia.
Uno más para entornos empresariales: en la CLI, las reglas ask de la empresa para comandos de shell, lecturas de archivos, escrituras de archivos y URLs pueden darse por satisfechas con la aprobación del modelo. Una regla ask ya no garantiza que una persona vea la solicitud.
La configuración sensata es usar permisos asistidos dentro de un entorno aislado, no en lugar de uno. Explicamos cómo activar el sandbox local de Copilot aquí: Sandbox local de GitHub Copilot: cómo activarlo en la CLI, la app y VS Code y qué no bloquea.
¿En qué planes de Copilot está disponible?
Al momento de publicar esta nota, ni el changelog ni la documentación de GitHub indicaban en qué planes de Copilot están incluidos los permisos asistidos.
¿Y tú? ¿Qué acción nunca dejarías que un modelo aprobara sin preguntarte?
Relacionado: GitHub Copilot Apuesta por la Autonomía — Y Construye el Guardrail para Contenerla
Top comments (0)