Copilot ya deja bloquear el auto-approve enterprise: el modo yolo empieza a tener dueño
GitHub anunció el 17 de junio de 2026 `disableBypassPermissionsMode`, una política para impedir que Copilot CLI y VS Code salten prompts de permiso automáticamente. Para equipos con agentes, el cambio vuelve administrable una práctica peligrosa.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
GitHub anunció el 17 de junio de 2026 una política enterprise que toca uno de los puntos más sensibles de los coding agents: el permiso para saltarse aprobaciones. Los administradores ya pueden usar disableBypassPermissionsMode para impedir que GitHub Copilot CLI y VS Code activen modos de aprobación automática como --yolo, --allow-all, /yolo o /allow-all.
La noticia importa porque el auto-approve no es solo un atajo. En un agente con shell, archivos, repos privados y herramientas MCP, saltar prompts puede convertir una tarea simple en un cambio irreversible. Hasta ahora, muchos equipos trataban ese riesgo como preferencia individual. GitHub lo está moviendo a política administrada.
Qué cambia en la práctica
La documentación oficial dice que la política vive en copilot/managed-settings.json dentro del repo .github-private de la empresa. También mantiene compatibilidad con la ruta legacy .github/copilot/settings.json.
El bloque mínimo se ve así:
{
"permissions": {
"disableBypassPermissionsMode": "disable"
}
}
GitHub marca la función como public preview, así que no conviene diseñar todo el programa de seguridad sobre esta pieza sola. Pero sí es una señal fuerte: las aprobaciones de agentes ya no son un detalle de UX, son parte del gobierno de plataforma.
Lo que no bloquea
El matiz importante está en la letra chica. GitHub dice que esta política bloquea los caminos que habilitan bypass combinado, pero no bloquea flags individuales como --allow-all-tools o --allow-all-paths.
Eso significa que un equipo serio todavía necesita una matriz más concreta:
- qué tools puede usar el agente;
- qué rutas puede modificar;
- qué comandos requieren aprobación;
- qué tareas pueden correr en sandbox;
- qué logs quedan después de cada sesión.
Bloquear yolo mode reduce blast radius, pero no reemplaza diseño de permisos.
Intención de búsqueda y oportunidad
No hay volumen SEO conectado aquí. La demanda se infiere por señales actuales: changelog oficial, documentación nueva de GitHub, adopción de Copilot CLI y búsquedas como disableBypassPermissionsMode, Copilot yolo mode, Copilot auto approve, GitHub managed settings agents y bloquear comandos agente IA.
Para Agente IA, el hueco en español está en explicar el tradeoff sin histeria. El modo yolo puede ser útil en sandboxes desechables, repos de práctica o tareas muy acotadas. Es peligroso cuando toca producción, secretos, migraciones, infraestructura o datos de clientes.
Criterio práctico para builders
Yo lo aplicaría así:
- desactiva bypass global en equipos enterprise por defecto;
- permite excepciones solo en sandboxes o repos de laboratorio;
- separa tools de lectura y tools de escritura;
- registra cada aprobación sensible;
- revisa si el agente pudo modificar archivos fuera del objetivo.
Si todavía estás definiendo el contrato base de tools, permisos y revisión, el curso gratis es mejor punto de partida que abrir permisos amplios por comodidad.
La conclusión corta: Copilot está reconociendo que la autonomía sin política central no escala. Un agente que ejecuta comandos necesita fricción bien puesta, no confianza ilimitada por default.