Code Guardian 17.9: qué cambia para usted

Con Code Guardian 17.8 y 17.9, lo que más notará es que los cerrojos leen comandos que hasta ahora pasaban por alto: scripts tras redirecciones, comandos en otros envoltorios de shell y scripts que se envían por la entrada estándar mediante ssh a un shell de un equipo remoto. Por ello, algunos comandos que hasta ahora se ejecutaban sin problema pueden detenerse ahora.

Además, Code Guardian comprueba una vez por proyecto si los ajustes de Claude Code o de Codex consumen mucho contexto, y el Council conserva sus veredictos durante 24 horas.

Este resumen abarca la 17.8 (en el portal de clientes desde el 10.10.2026) y la 17.9 (desde el 12.10.2026). El artículo sobre la versión anterior está en Code Guardian 17.7: novedades.

Lo que debería hacer ahora:

• Si la revisión de tokens (a partir de la 17.8) encuentra algo en el primer inicio de sesión tras la actualización, responda a su pregunta: ajustar o dejarlo como está. Solo se modifica con su «sí» expreso (versión de Claude). En la versión de Codex solo indica las líneas, y usted las ajusta a mano o las deja.
• Si un script tras una redirección se detiene (17.8), trátelo como cualquier otro script detenido: el camino a seguir es el mismo.
• Si trabaja con envoltorios de shell muy anidados, cuente con más preguntas o detenciones: cuando un envoltorio está más anidado de lo que Code Guardian lee, este pregunta (versión de Claude) o detiene el comando (versión de Codex).
• ¿Inicia sesiones mediante programación en Windows con Git Bash? Desde la 17.9, Code Guardian reconoce correctamente allí el terminal, y la aprobación del plan por una persona ya no se suprime por error. Si no puede leer los procesos padre, supone que hay un terminal.
• Si utiliza el Council, encontrará los veredictos completos de las últimas 24 horas en el libro de decisiones de su proyecto.

¿Qué cerrojos leen ahora más?

En pocas palabras: quien empaqueta comandos, los externaliza en scripts tras redirecciones o los envía a un equipo remoto será comprobado ahora con más frecuencia. En detalle:

Scripts tras redirecciones (17.8)

Cuando una redirección precedía a la llamada de un script, o el script llegaba por la entrada estándar, el cerrojo de borrado y el de migración no leían hasta ahora su contenido. Ahora lo leen también con estas formas de escritura. Por ello, los comandos que hasta ahora se ejecutaban pueden detenerse; el camino a seguir es el mismo que con cualquier otro script.

Más envoltorios de shell (17.9)

Un comando empaquetado en otra llamada de shell se lee ahora con más frecuencia. Esto vale para los envoltorios con opciones adicionales antes o después de la opción de inicio, para un segundo envoltorio dentro del primero, para shells menos habituales y para la forma de escritura de comillas que generan las herramientas al entrecomillar automáticamente.

Afecta sobre todo al cerrojo de borrado, y en parte también a la migración y al despliegue. Igualmente, el cerrojo de borrado lee ahora comandos dentro de las cadenas de texto de un intérprete de scripts, que allí inician a su vez un shell. Esta laguna ya existía en la 17.8.

Comandos remotos por ssh que ejecutan su entrada como programa (17.9)

Cuando un comando envía un script por la entrada estándar mediante ssh a un shell o a un intérprete de scripts de un equipo remoto, también detrás de sudo, el cerrojo de borrado lee ahora ese contenido como comando. Los datos que allí solo se almacenan o se leen siguen siendo datos.

Directorio raíz, directorio home y /tmp (17.9)

El cerrojo dejaba pasar algunas formas de escritura con las que un comando de borrado afectaba al directorio raíz, al directorio home o a /tmp en sí. Ahora las detiene.

Texto enviado mediante xargs a un cliente de base de datos (17.9)

El texto que llega mediante xargs a un cliente de base de datos se considera ahora SQL y se comprueba, también en formas de escritura que hasta ahora pasaban.

Despliegue con reinicio en el mismo comando (17.8, versión de Claude)

Un informe de autorización reciente autorizaba hasta ahora también un reinicio o una parada de un servicio en el equipo remoto si figuraba en el mismo comando. Ahora el despliegue sigue autorizado, y para la intervención en el estado en ejecución del equipo remoto Code Guardian pregunta. Las llamadas remotas de solo lectura y los comandos locales no desencadenan la pregunta. En una ejecución sin personas, esto supone una detención más.

Lo que esto significa para usted: Se trata de correcciones: los cerrojos leen formas de escritura que hasta ahora pasaban por alto, y en el despliegue con reinicio se añade una pregunta. Por ello, algunos comandos que hasta ahora pasaban inadvertidos se detienen o generan una pregunta.

¿Qué comprueba la nueva revisión de tokens? (versión de Claude)

Desde la 17.8, Code Guardian comprueba, una vez por proyecto en el primer inicio de sesión tras la actualización, si los ajustes de Claude Code consumen mucho contexto: el nivel de razonamiento, la ventana de compactación y el tamaño de los archivos de instrucciones. Si encuentra algo, muestra las líneas y le plantea una pregunta: ajustar o dejarlo como está.

• Solo se modifica con su «sí» expreso, únicamente el punto indicado, con copia de seguridad y una vía de retorno indicada.
• Los archivos de instrucciones nunca se modifican.
• En ejecuciones sin personas no se realiza la comprobación; la pregunta llega entonces en una sesión posterior.

Lo que la revisión no hace figura más abajo, en los límites. Cómo se comporta en la versión de Codex se explica en la sección para usuarios de Codex.

Lo que esto significa para usted: Usted decide. Sin su «sí», su configuración se queda como está.

¿Qué ocurre con el Council y el puesto de mando?

Libro de decisiones del Council (17.9)

El Council puede ahora volver a encontrar una decisión anterior, incluso después de que se haya condensado una sesión larga. El skill acompañante llm-council:

• inscribe cada veredicto completo en un libro de decisiones por proyecto (.code-guardian-evidence/council-entscheidbuch.md),
• lo lee al comienzo de la siguiente deliberación,
• deja caer las entradas de más de 24 horas,
• nunca muestra el libro a la mirada externa independiente,
• no inscribe las deliberaciones interrumpidas.

Puesto de mando (17.9, versión de Claude)

El nodo de cuota muestra la semana cuando no se informa de ninguna ventana de 5 horas, en lugar de «sin fuente de cuota». Sin sesión activa ya no aparece cortado por arriba, y su color sigue el mismo cálculo que la tarjeta contigua.

¿Qué cambia en Windows y en el registro?

• Detección del terminal en Git Bash (17.9). Hasta ahora, allí toda ejecución se consideraba «sin terminal», porque falla la consulta de los procesos padre. En un inicio mediante programación, por ello se suprimía la aprobación del plan por una persona. Ahora Code Guardian lee los procesos padre por una segunda vía; si no puede leerlos, supone que hay un terminal.
• Orquestador de sesiones en Windows (17.9, versión de Claude). Nunca podía determinar la propia sesión y rechazaba cualquier asignación; el inicio de sesión contaba allí una sesión libre de menos. Ahora la propia sesión se determina mediante la lista de procesos de Windows.
• Registro fail-open con sesiones que se inician a la vez (17.9). Cuando varias sesiones se iniciaban casi al mismo tiempo, podían aparecer líneas duplicadas en el registro o sobrescribirse un traspaso pendiente. Ahora un inicio solo recoge traspasos de inicios finalizados y no sobrescribe ninguno.
• Registro fail-open documentado (17.8). El README y la guía de actualización explican ahora el registro de los casos en que un cerrojo no pudo comprobar por falta de una herramienta, con la indicación de adónde se trasladan las líneas más antiguas. En Windows, el inicio de sesión avisa expresamente cuando un cerrojo no pudo convertir rutas (versión de Claude).

¿Qué otras correcciones y mejoras hay?

• El cerrojo de secretos de commit se detiene con menos frecuencia sin motivo en los merges (17.8). Un valor que en el mismo archivo ya figuraba en uno de los dos estados, por ejemplo tras cambiar el nombre de la clave, se considera ahora conocido. Un valor recién añadido, un valor de otro archivo y cualquier clave privada siguen deteniendo el commit, así como cualquier duda.
• Texto de rechazo del cerrojo de borrado corregido (17.8). El texto mencionaba /var/tmp como lugar desechable, pero el cerrojo nunca lo ha tratado así. El comportamiento no cambia; el texto ya no lo promete.
• La prueba de diseño mide con más precisión las páginas reales (17.8). En las páginas que solo se terminan de construir en el navegador, la sonda de estado mide tras la carga y tras el final de las transiciones. En el texto cuenta el punto dibujado más débil, de modo que una parte ilegible dentro de un enlace llama la atención.
• Prueba de diseño: etiquetas y esquemas de color (17.8). En casillas y botones de opción, la etiqueta visible y pulsable cuenta para el tamaño del objetivo. Las páginas con esquema de color claro y oscuro y fondo opaco se miden en lugar de interrumpirse. El número de hallazgos puede variar así en ambos sentidos.
• Detector de slop en monorepos (17.8). Lee las listas de paquetes entre el archivo y la raíz y ya no notifica las dependencias propias de un subpaquete como una importación inventada; una lista de paquetes dañada ya no interrumpe la ejecución.
• Carpeta de tareas y contador de fricción (17.8). Una carpeta de tareas con fecha en el nombre ya no recibe la fecha por duplicado. El contador de fricción ya no cuenta como fricción una prueba en rojo antes de la ejecución en verde ni una búsqueda sin resultados; por ello sus cifras no son comparables con las de retrospectivas anteriores.
• Externalizar la vista general de tareas (17.8, nuevo, solo bajo petición). La vista general de tareas puede externalizar a archivos de detalle los textos de los puntos terminados e inactivos, para que la lista siga siendo pequeña.

Lo que esto significa para usted: Menos detenciones innecesarias en el merge, y los hallazgos de la prueba de diseño pueden cambiar. No compare las cifras del contador de fricción con las de retrospectivas anteriores.

¿Qué límites siguen abiertos?

Los mencionamos en lugar de silenciarlos:

• Entrada estándar (17.8). Los cerrojos de borrado y de migración aún no leen algunas formas de escritura poco habituales con entrada estándar.
• Comandos remotos por ssh (17.9). El cerrojo de borrado aún no lee un shell de inicio de sesión sin comando propio ni los shells dentro de contenedores.
• Libro de decisiones del Council (17.9). El texto que parece un valor de acceso no se inscribe; con ello también puede rechazarse un valor inofensivo.
• Revisión de tokens (17.8). Los valores propuestos son nuestro ajuste predeterminado, no una medición de su proyecto. No comprueba los ajustes impuestos por la administración (versión de Claude).
• Orquestador en Windows (17.9, versión de Claude). Si falta un eslabón de la cadena, la propia sesión sigue siendo desconocida y el orquestador no asigna nada.

Lo que esto significa para usted: En los comandos de borrado y de migración con estas formas de escritura, no confíe únicamente en que salte un cerrojo.

¿Qué cambia para los usuarios de Codex?

El libro de decisiones del Council, la lectura ampliada de los envoltorios de shell, los comandos remotos por ssh, el cerrojo de borrado para directorio raíz, home y /tmp, el cerrojo de migración con xargs, el registro fail-open y la detección del terminal en Git Bash están en ambas versiones. Lo mismo vale desde la 17.8 para los scripts tras redirecciones, el cerrojo de secretos de commit, el texto de rechazo corregido, la prueba de diseño y las herramientas.

Diferencias que pueden acreditarse a partir de los textos:

• Envoltorio demasiado profundo (17.9). Cuando un envoltorio de shell está más anidado de lo que Code Guardian lee, la versión de Codex detiene el comando en lugar de preguntar.
• Revisión de tokens (17.8). La versión de Codex comprueba el nivel de razonamiento, el umbral de compactación y el tamaño del archivo de instrucciones, e indica las líneas. No modifica nada por sí misma: usted ajusta el valor a mano o lo deja. También allí los valores orientativos son nuestro ajuste predeterminado, y en ejecuciones sin personas no se realiza la comprobación.
• No figura en el texto de Codex. El texto de Codex no menciona el orquestador de sesiones en Windows (17.9), la corrección del puesto de mando (17.9) ni la pregunta en el despliegue con reinicio en el mismo comando (17.8).
• Skills acompañantes (17.8). La descripción de la versión de Codex menciona ahora cada skill acompañante incluido, en una línea.

Lo que esto significa para usted: Con Codex, en la revisión de tokens la decisión y el trabajo manual siguen en sus manos, y un envoltorio demasiado anidado provoca un comando detenido.

Estado de la medición comparativa: la última ejecución válida, del 08.10.2026, mide la v17.7: de media 5,7 con frente a 5,0 sin Code Guardian, p = 0,13, resultado «no concluyente». Para la 17.8 y la 17.9 no hay medición propia; en total, en ese momento había 9 comparaciones válidas.

Encontrará más información sobre el producto en la página del producto.

Preguntas frecuentes sobre Code Guardian 17.8 y 17.9

¿Tengo que hacer algo tras la actualización?

Usted debe actuar cuando la revisión de tokens encuentre algo y pregunte (versión de Claude; con Codex ajusta a mano las líneas indicadas), y allí donde se detenga un comando.

¿La revisión de tokens cambia mis ajustes por sí sola?

No, véase más arriba: solo con su «sí» expreso, y en la versión de Codex en absoluto.

¿Por qué se detiene un comando que hasta ahora se ejecutaba?

Porque los cerrojos leen ahora formas de escritura que antes pasaban por alto, por ejemplo scripts tras redirecciones o comandos en otros envoltorios de shell.

¿Dónde encuentro los requisitos, los ajustes y el paquete?

Los requisitos y los ajustes figuran en la documentación técnica. El paquete está en el portal de clientes. Cómo se mantiene Code Guardian actualizado después se explica en provimedia.de/code-guardian/updates.

Fuentes

• Resúmenes de cambios publicados («Novedades») de las versiones 17.8 y 17.9, versiones de Claude y de Codex (portal de clientes)

Fecha: 12.10.2026