GitHub lleva managed-settings.json a GA: Copilot ya puede tener defaults empresariales para modelos y plugins

GitHub anunció el 1 de julio de 2026 que enterprise managed-settings.json ya está en disponibilidad general. En la práctica, una empresa puede mantener un archivo copilot/managed-settings.json dentro de un repositorio .github-private y aplicar configuración central a clientes como VS Code y Copilot CLI.

Ese mismo día GitHub agregó una mejora relacionada: los administradores pueden fijar model en auto para que las conversaciones nuevas arranquen con auto model selection por defecto. El usuario todavía puede cambiar de modelo por conversación, pero el punto de partida deja de depender de una decisión local o de memoria.

Qué se mueve de la laptop al control empresarial

El archivo soporta claves como extraKnownMarketplaces, enabledPlugins, strictKnownMarketplaces, disableBypassPermissionsMode y model. No es una lista decorativa: GitHub dice que esta configuración tiene precedencia sobre configuración local basada en archivos para las claves soportadas, se descarga cuando el usuario autentica y se refresca cada hora.

Para equipos con agentes de coding, eso cambia el contrato. Ya no basta con decir "instala este plugin" o "usa este modelo". Puedes definir standards que Copilot recibe desde una fuente administrada:

• marketplaces permitidos o adicionales;
• plugins habilitados;
• bloqueo de modos de bypass de permisos;
• modelo inicial o selección automática;
• ruta única para gobernanza en .github-private.

Auto model selection no es solo comodidad

La selección automática de modelo suele venderse como ahorro de decisión. Para agentes, también es control de variabilidad. Si cada developer elige un modelo distinto para la misma clase de tarea, comparar costo, calidad y fallos se vuelve más difícil.

Poner model: auto como default permite que Copilot enrute según tarea sin que el equipo mantenga una matriz manual de modelos por cliente. Pero conviene leer el tradeoff completo: delegas parte de la decisión al proveedor, así que necesitas métricas, sesiones auditables y una forma de detectar cuándo el routing no sirve para tu repo.

El error común: tratarlo como archivo de preferencias

managed-settings.json no debería ser el lugar donde se acumulan gustos personales. Debería ser una política mínima y revisable.

Un buen primer corte sería:

1. permitir solo marketplaces revisados;
2. habilitar plugins que tengan owner y caso de uso;
3. bloquear bypass de permisos en repos sensibles;
4. usar auto donde el equipo acepte routing administrado;
5. documentar quién aprueba cambios al archivo;
6. revisar mensualmente si alguna regla está frenando trabajo legítimo.

La peor versión es copiar una configuración enorme sin explicar por qué existe. Eso convierte gobernanza en fricción muda. La mejor versión es corta, auditable y alineada con riesgos reales: secretos, producción, dependencias, costo y permisos de herramientas.

Demanda e intención

No hay tooling SEO conectado en esta corrida. La demanda se infiere por señales oficiales: GA de managed-settings.json, soporte de auto model selection, crecimiento de Copilot CLI y agentes en VS Code, y queries como managed-settings.json Copilot, Copilot enterprise settings, Copilot auto model selection y Copilot plugins governance.

Agente IA puede competir porque el ángulo en español no debería ser "otro JSON". La lectura útil es que la configuración de agentes empieza a parecer infraestructura, con repositorio fuente, refresh, precedence y owners.

Si tu equipo apenas está definiendo instrucciones de agente, empieza por el curso gratis. Si ya corres Copilot en varios equipos, esta noticia debería convertirse en una tarea concreta: sacar reglas críticas de laptops individuales y ponerlas bajo revisión empresarial.