Un administrador cambia hoy la política de Copilot para impedir una operación delicada. Mañana un desarrollador abre el cliente sin conexión y el programa arranca con la copia de ayer. Ese retraso es precisamente el caso que aborda la actualización de GitHub del 13 de octubre: ahora una empresa puede exigir que ciertos clientes consulten la política actual antes de iniciar.

La nueva clave forceRemoteSettingsRefresh acepta true en la configuración administrada. GitHub la admite en Copilot CLI, VS Code y la aplicación GitHub Copilot. Con ella activa, la caché ya no basta para cumplir el requisito de frescura: si el cliente no puede confirmar la política vigente, bloquea el uso en vez de operar con una política antigua. Es un cambio relevante para equipos con controles de seguridad, pero también puede afectar la disponibilidad si la red o el servicio de políticas fallan.

Lo que cambia en la práctica

La opción puede distribuirse por ajustes administrados en el servidor, por MDM o mediante un archivo local. Hay una diferencia que importa en el primer inicio: MDM y archivo pueden imponerla antes de que el usuario inicie sesión; una política del servidor solo exige el refresco en arranques posteriores, una vez que el cliente la recibió. Por eso, publicar la clave en el repositorio de políticas no equivale a asegurar el primer arranque de una máquina nueva.

Sin esta clave, los clientes conservan el comportamiento normal de caché, pensado para iniciar más rápido y tolerar fallos transitorios. La decisión no es “seguridad o inseguridad” en abstracto: es cuánto tiempo puede aceptar tu organización una política local potencialmente desactualizada y qué interrupción tolera cuando no se puede consultar el servidor.

Cómo probarla sin cortar a toda la organización

1. Identifica la política concreta que exige actualización inmediata. Si una regla puede esperar el ciclo habitual de sincronización, quizás no necesita esta opción.
2. Comprueba que el cliente usado por el grupo piloto sea compatible: Copilot CLI, VS Code o la aplicación Copilot.
3. En un piloto, agrega "forceRemoteSettingsRefresh": true a la configuración administrada. Para despliegue del servidor, GitHub documenta el archivo copilot/managed-settings.json en el repositorio .github-private; para archivo local, usa la ruta documentada del sistema operativo.
4. Prueba dos escenarios: inicio con conexión y políticas disponibles, e inicio cuando la consulta al servidor falla. Mide cuántos usuarios quedan detenidos y cómo reciben soporte.
5. Comunica el comportamiento esperado antes de extender la regla y mantén un procedimiento de reversión administrado por TI.

Un ejemplo mínimo de la clave dentro de JSON es:

{
  "forceRemoteSettingsRefresh": true
}

No copies ese objeto como política completa sin revisar los demás ajustes de tu empresa. GitHub indica que los despliegues MDM en macOS y Windows usan valores de cadena por clave, mientras el despliegue basado en archivo usa JSON. Para Copilot CLI en macOS y Linux, ese archivo debe ser regular, pertenecer a root y no permitir escritura de grupo o de otros usuarios.

También cambia el control de versiones antiguas

GitHub agregó un requisito de versión mínima para la clave administrada sandbox. Si la organización la incluye, clientes antiguos fijados a versiones anteriores tendrán que actualizarse para volver a usar Copilot. Esto evita que una política de aislamiento parezca aplicada cuando el cliente es demasiado viejo para implementarla correctamente, pero exige inventariar versiones antes del despliegue.

Mi recomendación operativa es probar ambas cosas por separado: primero el requisito de política fresca, después la clave sandbox. Si aparecen incidencias, sabrás si el problema es conectividad o versión. Documenta el resultado con hora, versión de cliente, método de entrega de la política y resultado del arranque. Esa pequeña tabla hará más útil la decisión que activar una casilla y asumir que toda la flota quedó protegida.

Fuentes: anuncio oficial de GitHub, 13 de octubre de 2026; guía oficial de despliegue.