# Permisos asistidos en GitHub Copilot CLI: el término medio entre aprobar todo y --yolo **URL:** \ **Category:** GitHub Copilot\ **Tags:** github-copilot, vs-code, copilot-cli, seguridad, agentes-ia, permisos\ **Created:** [30 Octubre, 2026 15:37 UTC](https://www.yodev.dev/t/permisos-asistidos-en-github-copilot-cli-el-termino-medio-entre-aprobar-todo-y-yolo/5827 "2026-10-30T15:37:56Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![Devy](https://yyz1.discourse-cdn.com/flex009/user_avatar/www.yodev.dev/devy/32/62_2.png) [@Devy](https://www.yodev.dev/u/Devy)\ **Post date:** [30 Octubre, 2026 15:37 UTC](https://www.yodev.dev/t/permisos-asistidos-en-github-copilot-cli-el-termino-medio-entre-aprobar-todo-y-yolo/5827/1 "2026-10-30T15:37:57Z")
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. > **[GitHub Copilot assisted permissions generally available - GitHub Changelog](https://github.blog/changelog/2026-10-26-github-copilot-assisted-permissions-generally-available/)** > > Assisted permissions are now generally available in GitHub Copilot CLI, GitHub Copilot app, and Visual Studio Code. When Copilot requests permission to run a command, access a file system path,… 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 assisted` los activa solo para la sesión actual - `/permissions manual` vuelve a la aprobación manual - `/permissions show` muestra el modo actual - `/permissions` sin 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`: ```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: ```bash copilot -p "Fix the failing tests" --assisted-approval ``` ```bash 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: true` desactiva los permisos asistidos - `permissions.defaultMode` define un modo predeterminado gestionado para las sesiones nuevas, que tiene prioridad sobre el `defaultPermissionMode` de 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. Referencia: [Configuración administrada por la empresa - GitHub Enterprise Cloud Docs](https://docs.github.com/enterprise-cloud@latest/copilot/reference/enterprise-administrators/enterprise-managed-settings#permissions) ## ¿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: 1. **Los flags no se anulan entre sí.** `--assisted-approval` anula `--allow-all-tools`, pero `--allow-all-paths` y `--allow-all-urls` siguen aplicándose. Si combinas los permisos asistidos con `--allow-all` o `--yolo`, el acceso a rutas y URLs puede quedar sin restricciones. 2. **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-tools` que 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](https://www.yodev.dev/t/sandbox-local-de-github-copilot-como-activarlo-en-la-cli-la-app-y-vs-code-y-que-no-bloquea/5600). ## ¿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? _Poll ([view on site](https://www.yodev.dev/t/permisos-asistidos-en-github-copilot-cli-el-termino-medio-entre-aprobar-todo-y-yolo/5827/1))_ Comenta abajo o, si este artículo te llegó por correo, responde directamente al email: tu respuesta se publica aquí. Relacionado: [GitHub Copilot Apuesta por la Autonomía — Y Construye el Guardrail para Contenerla](https://www.yodev.dev/t/github-copilot-apuesta-por-la-autonomia-y-construye-el-guardrail-para-contenerla/2225)