Claude Code 2.1.314 cierra un fail-open de las políticas gestionadas y añade un ajuste que bloquea las escrituras fuera de los directorios de trabajo

Actualiza ahora si las barreras de seguridad de tu Claude Code viven en los ajustes gestionados. Claude Code 2.1.314, fechado el 30 de octubre de 2026 en el changelog de Anthropic, corrige un caso en el que una sesión podía iniciarse sin ninguna política. También cierra tres brechas más concretas en el entorno aislado, los hooks y las fuentes de ajustes, y añade el primer ajuste que hace que las herramientas de archivos de Claude rechacen escrituras fuera de los directorios de trabajo en todos los modos de permisos. Nuestra calificación de Claude Code sigue en condicional: es una versión de endurecimiento rutinaria, y la respuesta correcta es actualizar, no replantearse la herramienta.

Qué ha pasado

El fail-open de la política gestionada

El changelog, literalmente: «Corregido: forceRemoteSettingsRefresh, configurado solo en los ajustes gestionados remotos, dejaba de aplicarse una vez caducada la copia almacenada, lo que permitía iniciar sesiones sin política cuando no se podía contactar con el servidor».

En la práctica: una organización que configuraba forceRemoteSettingsRefresh solo en sus ajustes gestionados remotos esperaba que Claude Code se negara a funcionar sin gestión. Una vez caducada la copia en caché, ese indicador dejaba de aplicarse, así que una máquina que no podía contactar con el servidor de ajustes iniciaba una sesión sin política. Las máquinas que nunca perdieron contacto con el servidor no estaban expuestas por esta vía.

Tres correcciones más de permisos y entorno aislado

Todas literales, de la entrada 2.1.314:

• «Corregido: las protecciones del entorno aislado no se aplicaban a un worktree al que se entraba con claude -p --resume o --continue»
• «Corregido: un archivo de ajustes excluido con --setting-sources seguía aportando algunos ajustes, como las reglas del modo auto y los consentimientos de permisos guardados»
• «Corregido: los hooks que coinciden con Bash no se ejecutaban en comandos de shell iniciados por la herramienta Monitor; esos hooks pueden bloquear o preguntar, pero no aprobar ni reescribir esos comandos»

Nuevos ajustes de endurecimiento

• «Añadido permissions.blockWritesOutsideWorkingDirectories: Write, Edit y NotebookEdit rechazan rutas fuera de los directorios de trabajo en todos los modos de permisos»
• «Modificado: las herramientas de archivos de Claude ahora preguntan antes de editar la copia local de los ajustes gestionados por el servidor de tu organización, igual que hacen con tus archivos de ajustes»
• «Modificado: las solicitudes marcadas ahora reintentan con otro modelo en lugar de terminar en un rechazo, cuando ANTHROPIC_DEFAULT_OPUS_MODEL, availableModels o deniedModels dejan solo un modelo Opus más antiguo, o ninguno»

La misma entrada añade la compactación en reposo a VS Code y a la pestaña Code de Claude Desktop: «una conversación de más de 200.000 tokens que queda inactiva se resume, y el resumen se usa en tu siguiente mensaje si la caché del prompt ha caducado».

Por qué importa

El fail-open es el titular. forceRemoteSettingsRefresh existe para que una máquina gestionada no funcione sin política, y falló exactamente en el caso para el que estaba pensado: una caché caducada más un servidor inaccesible. Cualquier regla de denegación, ajuste de entorno aislado o restricción de modelos entregada mediante ajustes gestionados remotos estuvo ausente de esas sesiones.

Las otras tres correcciones eliminan cada una una vía de escape silenciosa:

• Trabajos headless reanudados. Quien reanudaba trabajos de claude -p en worktrees con entorno aislado los ejecutaba sin las protecciones del entorno aislado.
• Archivos de ajustes excluidos. Un archivo excluido con --setting-sources podía seguir introduciendo reglas del modo auto y consentimientos de permisos guardados en una sesión.
• Comandos de la herramienta Monitor. Los comandos de shell iniciados por la herramienta Monitor se saltaban los hooks de Bash, así que un hook de bloqueo no se activaba sobre ellos.

El nuevo ajuste permissions.blockWritesOutsideWorkingDirectories cubre solo las herramientas de archivos de Claude (Write, Edit y NotebookEdit). El changelog no dice que se aplique a Bash, así que un comando de shell todavía puede escribir en otro lugar salvo que el entorno aislado o una regla de denegación lo impida.

Qué cambia para ti

• Flotas gestionadas: actualiza todas las máquinas a 2.1.314, empezando por las que dependen de forceRemoteSettingsRefresh para bloquear sesiones sin política.
• Pipelines headless: si ejecutas claude -p --resume o --continue dentro de worktrees con entorno aislado, actualiza antes de la próxima ejecución.
• Ejecuciones desatendidas: considera activar permissions.blockWritesOutsideWorkingDirectories en los ajustes gestionados o del proyecto, y combínalo con el entorno aislado o con reglas de denegación de Bash, ya que no cubre los comandos de shell.
• Equipos que usan --setting-sources: tras actualizar, vuelve a comprobar qué reglas del modo auto y qué consentimientos de permisos guardados siguen aplicándose.

Lo que esto no te dice

El changelog no nombra ningún CVE ni enlaza a ningún aviso, así que no hay calificación oficial de gravedad. No existe una entrada 2.1.313: el changelog pasa de 2.1.312 (27 de octubre) directamente a 2.1.314, sin dar ninguna razón. No hemos probado 2.1.314 nosotros mismos.