Claude Code 2.1.92 agregó una configuración con una consecuencia poco habitual para una herramienta de desarrollo. forceRemoteSettingsRefresh puede impedir que la CLI abra cuando no consigue descargar las políticas remotas de la organización. Sin actualización, la sesión termina. No continúa con reglas antiguas en caché ni ofrece un modo degradado para que el usuario decida después.
Ese comportamiento cambia disponibilidad local por certeza de política. La elección tiene sentido donde el riesgo de que un agente opere con permisos obsoletos supera el costo de interrumpir el trabajo. También demuestra que distribuir un agente en una empresa exige controles distintos a los de una instalación individual.
La versión añadió disableSkillShellExecution, que bloquea comandos de shell iniciados por skills y plugins, y elevó a 500.000 caracteres la persistencia de resultados MCP. Los tres cambios tratan una misma tensión: los agentes necesitan contexto y herramientas, pero cada capacidad amplía la superficie que una organización debe gobernar.
Fail-closed es una decisión operativa
Los sistemas fail-open siguen funcionando cuando falla el mecanismo de control. Conservan disponibilidad, aunque aceptan un período con políticas posiblemente desactualizadas. Los sistemas fail-closed bloquean la operación hasta confirmar las reglas. La seguridad aumenta junto con una dependencia nueva: el servicio que entrega la configuración entra en el camino crítico.
Activar la opción sin preparar la operación solamente traslada el incidente. Un fallo de red, DNS, autenticación o disponibilidad del endpoint puede detener a decenas de ingenieros. El equipo debe monitorear el servicio de configuración, definir objetivos de disponibilidad y distinguir un bloqueo legítimo de un problema del plano de control.
El primer acceso también requiere planificación. Máquinas nuevas, runners efímeros y sandboxes comienzan sin estado confiable. Si la política remota es obligatoria, autenticación y conectividad deben existir antes de abrir el agente. La documentación de onboarding debe tratarlas como requisito.
Bloquear shell en skills reduce la confianza transitiva
Una skill puede parecer un archivo de instrucciones y contener ejecución de comandos. Los plugins combinan orientaciones, scripts e integraciones externas. Cuando un ingeniero instala ese paquete, la organización hereda la confianza depositada en el autor, repositorio, mecanismo de actualización y dependencias del script.
disableSkillShellExecution crea una frontera central. El agente sigue leyendo instrucciones, mientras la parte capaz de ejecutar en el sistema recibe una restricción explícita. Así, una empresa puede permitir extensiones para patrones de código y documentación sin autorizar acciones locales de forma automática.
El control no elimina todos los riesgos. Una instrucción maliciosa puede intentar convencer al agente de usar otra herramienta autorizada. Los permisos de archivos, red, secretos y comandos siguen siendo necesarios. La opción reduce una ruta de ejecución y simplifica la revisión, pero no sustituye al sandbox ni a una allowlist.
Más contexto persistente también necesita límites
Elevar a 500.000 caracteres la persistencia de resultados MCP evita truncar schemas, volcados de configuración y consultas extensas. El agente puede consultar ese material más tarde sin repetir la llamada. Una investigación técnica conserva continuidad y evidencia.
El beneficio trae dos preguntas. La primera es si el resultado contiene secretos, datos personales o información de otro entorno. La persistencia amplía el tiempo y los lugares donde puede aparecer ese contenido. La segunda es si el volumen ayuda. Medio millón de caracteres irrelevantes puede perjudicar la selección de contexto y aumentar el costo.
Los servidores MCP deberían devolver solo los campos necesarios, paginar colecciones grandes y marcar contenido sensible. Un techo mayor resuelve truncamiento, pero no reemplaza un contrato de respuesta adecuado.
Una implantación corporativa mínima
Antes de exigir la actualización remota, una organización puede ejecutar un piloto pequeño. La prueba incluye pérdida de conexión, credencial expirada, endpoint indisponible y política inválida. Cada escenario debe producir un mensaje que permita al soporte identificar la causa sin pedir al usuario que desactive el control.
Después conviene separar políticas universales de configuraciones por repositorio. Las restricciones de secretos y ejecución pueden ser globales. Los comandos de build y las rutas permitidas pertenecen más cerca del proyecto. Una configuración central enorme resulta difícil de revisar y puede bloquear trabajo legítimo sin explicar el motivo.
Los logs necesitan registrar la versión de política aplicada, la hora de la última actualización y la causa del bloqueo. La gobernanza que solo impide una sesión genera tickets; la gobernanza observable permite auditoría.
El modo fail-closed señala madurez del producto y crea una obligación para quien lo activa. La empresa puede afirmar que ninguna sesión comenzó fuera de sus reglas actuales. A cambio, debe operar la distribución de esas reglas como parte de la infraestructura de ingeniería.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
