Code Guardian 17.3: qué cambia para usted

Code Guardian 17.3 está en el portal de clientes desde el 02.10.2026. Tras la actualización, se le interrumpirá con menos frecuencia, tanto al final de la sesión como con comandos habituales. A cambio, doce cerrojos quedan dados de baja: sus comprobaciones pasan a ser únicamente una instrucción de trabajo. Aquí leerá qué bloqueos son ahora responsabilidad suya y qué debería hacer antes y después de la actualización.

Qué debería hacer ahora:

• Repase la tabla de bloqueos dados de baja que aparece más abajo. Donde usted confiaba en alguno, la comprobación debe formar ahora parte de su propio flujo de trabajo. La salida de la actualización indica cuáles estaban registrados en su caso, en la línea «REMOVED (Riegelkern, …)».
• ¿Utiliza informes de autorización para migraciones? Entonces vuelva a crear los informes antiguos siguiendo las instrucciones de más abajo. Un informe sin la línea FREIGABE-FUER ya no autoriza nada.
• ¿Necesita el gate jurídico o el gate de análisis de datos? Entonces actívelos (instrucciones más abajo).
• ¿Utiliza Codex? Entonces compruebe antes de la actualización, con codex --version, que dispone como mínimo de la versión 0.150.0.

¿Qué es el núcleo de cerrojos (Riegelkern)?

Un cerrojo es una comprobación que puede detener un comando o una acción. Hasta ahora, muchísimos de ellos detenían. En la 17.3, solo siguen bloqueando los cerrojos con un potencial real de causar daño.

• DESTRUCTIVE detiene los comandos de borrado arriesgados.
• COMMIT-SECRET detiene un commit que contiene un secreto.
• DEPLOY detiene un despliegue para el que no existe un informe autorizado.
• MIGRATION detiene los cambios en la base de datos para los que no existe un informe de autorización.
• La protección contra escritura para las ejecuciones sin supervisión está definida de forma estricta. Solo bloquea ya la autoprotección de los cerrojos y de los archivos de configuración, así como la escritura de credenciales de acceso.
• El DECISION GATE solo detiene ya una pregunta con opciones en el autopiloto. Allí decide el llm-council. En los demás casos solo emite un aviso.

Con independencia de los doce cerrojos dados de baja que figuran más abajo, otros hooks, entre ellos el inicio de sesión y la comprobación de prompts, solo emiten ya avisos.

Para usted, esto significa: recibirá menos preguntas y rechazos. Los cuatro cerrojos de comandos le siguen protegiendo frente al borrado, los secretos en el commit, el despliegue y la migración.

¿Qué bloqueos son ahora responsabilidad suya?

Esto es una restricción, no una mejora. Las reglas siguen en el skill, pero una infracción ya no le detiene técnicamente. Quien confiaba en uno de estos bloqueos, por ejemplo en que se detuviera la instalación de un paquete nuevo, debe asumir ahora la comprobación por su cuenta. Esto vale también para la prueba del segundo revisor en frío, es decir, de un revisor independiente que lee su cambio sin conocimiento previo.

La valla de alcance (scope fence) figura en una sola línea porque le corresponden dos archivos (uno fija el alcance y otro bloqueaba las escrituras fuera de él).

La actualización elimina las entradas de estos cerrojos de su settings.json. Un hook con el mismo nombre en otra carpeta, que usted mismo haya registrado, lo deja donde está. Los archivos de los cerrojos dados de baja permanecen en esta versión en el paquete y en ~/.claude/hooks/, pero ya no se ejecutan. Su eliminación está prevista para la v17.4.

¿Cómo vuelvo a crear un informe de autorización para migraciones?

Un informe de autorización solo es válido ahora para los tipos de comando que nombra su línea FREIGABE-FUER: <arten>. La herramienta la escribe al volver a crear el informe con el valor predeterminado migrate. Un informe antiguo no tiene esa línea y, por tanto, ya no autoriza nada.

La llamada a la herramienta de informes gate-report.py del skill code-guardian es la siguiente:

gate-report.py migration (--files F... | --git [--ref REF]) [--wurzel DIR] [--fuer ART[,ART]]

1. Vuelva a crear el informe con la herramienta, ya sea con --files y los archivos de migración o con --git.
2. Si debe autorizar más que migrate, indique los tipos con --fuer, por ejemplo --fuer migrate,seed. Se permiten migrate, seed, rollback, fresh, refresh, reset, wipe y ddl. Los tipos destructivos indíquelos solo de forma expresa.
3. Compruebe en el informe terminado que la línea FREIGABE-FUER está presente y nombra los tipos deseados.

¿Qué correcciones de seguridad incluye la 17.3?

Son correcciones en los cerrojos que siguen bloqueando. Los comandos que hasta ahora pasaban sin comprobación se verifican ahora.

• Un informe de autorización para una migración autorizaba hasta ahora cualquier comando de migración de la misma raíz del proyecto, incluidos migrate:fresh y migrate:rollback. Ahora solo autoriza los tipos que figuran en FREIGABE-FUER. Lo notará enseguida si su informe es antiguo.
• Un comando de borrado escrito en dos formas anidadas concretas se saltaba el cerrojo de borrado. Ahora comprueba ambas.
• Si se pasaba un dato dos veces a la herramienta de informes, una migración desaparecía silenciosamente del informe y este la clasificaba como demasiado inofensiva. Ahora se tienen en cuenta ambos datos. De todos modos, los informes antiguos debe volver a crearlos (véase más arriba).

¿Cómo activo el gate jurídico y el gate de análisis de datos?

Ambos gates son ahora activables y están desactivados por defecto. Para activarlos, introduzca esta línea en ~/.claude/code-guardian.conf:

riegel_zusatz = rechts, data-analytics

A continuación, ejecute bash install.sh. Si solo quiere uno de los dos, indique únicamente ese.

Para usted, esto significa: quien elabora textos jurídicos o análisis de datos activa los gates. Hasta ahora ambos estaban en marcha; ahora están desactivados hasta que usted los active.

¿Qué límites siguen abiertos?

Primero, los límites que afectan a su flujo de trabajo:

• Cerrojos de migración y de despliegue: en algunas formas de comando y de escritura, el cerrojo de migración aún no asigna en todos los casos una migración o su informe de autorización a la raíz de proyecto correcta. El cerrojo de despliegue solo reconoce un script de transferencia por nombres conocidos. Ambos puntos están previstos para la v17.4. Hasta entonces, compruebe usted mismo, en sus propios scripts y en formas de comando inusuales, si el cerrojo ha actuado.
• Informe de autorización: está vinculado a tipos de comando, no a un archivo de migración concreto.
• Correcciones de seguridad: afectan a formas de escritura conocidas. No afirmamos que con ello quede cubierta cualquier forma. En los comandos de borrado, no confíe únicamente en el cerrojo.
• Subagentes de comprobación: trabajan en el árbol de trabajo compartido. Que no toquen allí trabajo ajeno que no esté confirmado en el repositorio es, en esta versión, una instrucción de trabajo. Haga antes una copia de seguridad del trabajo no confirmado.

Y los límites de comprobaciones concretas:

• La búsqueda de secretos reconoce formas conocidas de credenciales en texto legible y no realiza ningún análisis de flujo de datos. En un archivo con una codificación de dos bytes (UTF-16) solo puede comprobar de forma limitada.
• design-beweis puede medir demasiado pronto las páginas que construyen su contenido solo después de cargarse. No evalúa el contraste en páginas con esquema de color conmutable. La corrección está prevista para la v17.4.
• Solo Codex: con un CODEX_HOME propio, algunas indicaciones de reparación siguen remitiendo a ~/.codex, y el análisis de incidentes al final de la sesión no se realiza. La corrección está prevista para la v17.4.

Para usted, esto significa: en migraciones y despliegues, hasta la v17.4 no confíe únicamente en que el cerrojo actúe.

¿Qué hay de nuevo en la búsqueda de secretos y en las comprobaciones de análisis?

Ambas dicen ahora «no medido» o «no comprobado» donde antes habrían mostrado un resultado en verde.

• La búsqueda de secretos asigna cada archivo exactamente a una clase e indica, con su número, lo que no ha examinado («no comprobado: …»).
• Hasta ahora solo buscaba en archivos con una extensión conocida. Un archivo de PowerShell, un .ini, un .toml o un Dockerfile se consideraban limpios sin más. Ahora se examinan.
• Si no se examinó nada aunque había archivos, el resultado no es «limpio». Si falta python3, la búsqueda informa «no comprobado».
• Si falta una herramienta de análisis configurada, se bloquea o supera su plazo, las comprobaciones de análisis informan «no medido». El plazo se ajusta con CG_ANALYSE_FRIST. El valor predeterminado es de 900 segundos.

Una precisión honesta: un archivo con una cadena de caracteres muy larga en una sola línea puede hacer que la búsqueda de secretos tarde desde unos segundos hasta más de medio minuto. El resultado sigue siendo completo.

Para usted, esto significa: donde no se ha comprobado, el resultado ya no muestra verde, sino que lo dice.

¿Qué pasa con la línea de estado?

La línea de estado se ha eliminado. Con muchas sesiones paralelas, costaba un tiempo de cálculo apreciable. Code Guardian ya no registra ninguna, y una actualización retira la que registramos antes:

• Una línea combinada vuelve a su propio comando.
• Una línea de estado propia permanece sin cambios.
• Si ha integrado nuestro script anterior de una forma distinta a como lo escribió nunca el instalador, la línea permanece con una advertencia. En ese caso, límpiela usted mismo si lo necesita.
• Los antiguos conmutadores --statuszeile=… y --statuszeile-kombinieren se siguen aceptando y se ignoran.
• La copia de seguridad de su línea de estado anterior no se elimina si puede ser la única copia.
• El skill de panel clistatus se mantiene.
• La marca de señal naranja, que debía mostrar que un cerrojo había intervenido, desaparece con la línea de estado. Que un cerrojo intervenga no depende de la línea de estado.

Para usted, esto significa: si tenía una línea de estado propia, no cambia nada. Si tenía la nuestra, la actualización la retira. Solo una integración que el instalador nunca escribió permanece con una advertencia.

¿Qué cambia en Windows y al iniciar la sesión?

• Con un jq.exe nativo, el aviso de resultado nulo no llegaba nunca. Ahora llega.
• La comprobación de prompts es más rápida. Su trabajo de texto por prompt se realiza en una sola llamada a python3 en lugar de en muchos procesos pequeños.
• Si un cerrojo había notificado él mismo una avería, el siguiente inicio de sesión era apreciablemente más lento, sobre todo en Windows. El análisis del registro de averías lanzaba muchos procesos pequeños y ahora se realiza en una sola pasada. El mensaje no cambia.
• Si el análisis se interrumpe, el inicio de sesión lo indica en una línea visible y deja el registro donde está. Antes lo trasladaba en silencio al historial.

Para usted, esto significa: tras una avería de un cerrojo, la siguiente sesión arranca más rápido en Windows y un error ya no pasa inadvertido.

¿Qué hay de nuevo en los ajustes, las herramientas y la documentación?

El instalador recoge ahora su elección en code-guardian.conf también cuando el archivo ya existe. Un ajuste documentado que todavía falte allí lo añade al final con su valor predeterminado. Sus líneas permanecen sin cambios.

En las herramientas hay cambios menores. jsqa-onboard activa la traza de Playwright cuando hay fallos. La lista de tareas comprueba sus reglas de formato antes de escribir. El skill session-orchestrator tiene una bandeja de entrada de encargos con plazo y crea un árbol de trabajo propio para cada sesión. La documentación está corregida: se han sustituido las cifras obsoletas y se menciona Windows como plataforma compatible.

¿Qué cambia para los usuarios de Codex?

La búsqueda de secretos, las comprobaciones de análisis, las correcciones de seguridad, los ajustes y el análisis más rápido del registro de averías al iniciar la sesión equivalen a la edición de Claude. El aviso de jq.exe y la comprobación de prompts más rápida solo valen para Claude Code. Lo siguiente es distinto:

• El nuevo requisito es codex-cli 0.150.0 o posterior. La actualización se interrumpe sin cambiar nada si codex no está en el PATH o es más antiguo. Compruébelo con codex --version. Puede actualizar, por ejemplo, con npm install -g @openai/codex@latest.
• Los cerrojos dados de baja en Codex no son los mismos que en la tabla anterior. Ya no están enganchados allí, entre otros, el airlock previo al primer cambio de archivo, la valla del proyecto, el cerrojo de dependencias y todos los cerrojos del final de la sesión. Sus reglas siguen figurando como instrucción de trabajo en los skills.
• Los cerrojos adicionales para textos jurídicos y análisis de datos no se pueden activar en Codex en esta versión.
• El aviso que Codex muestra en cada prompt ya no nombra herramientas que solo existen en Claude Code. En su lugar, exige un plan con update_plan y la respuesta de la persona.

Para usted, esto significa: compruebe la versión de Codex antes de actualizar. Eso le ahorra una ejecución interrumpida.

¿Cómo se probó la 17.3 y qué dice la medición comparativa?

La 17.3 pasó por la batería de pruebas antes de su publicación. La tabla muestra las cifras en comparación con la 17.2.

Como contexto: se han añadido 16 niveles. Uno ha desaparecido, el de la línea de estado. Las dos direcciones de error de los cerrojos se superaron por completo: actúan cuando deben y dejan pasar con razón lo que está permitido.

Desde el artículo sobre la 17.2 no hay ninguna nueva medición comparativa válida. Por eso, para la 17.3 no podemos indicar ninguna cifra, y no inventamos ninguna. Sobre todas las comparaciones válidas de la v16.116 a la 17.2 (8 mediciones) sigue siendo cierto: 4 con diferencia demostrada, 3 no decidibles, 1 sin diferencia demostrada.

Conclusión: la batería de pruebas se ejecutó sin ningún fallo; cinco niveles se omitieron en modo rápido, con indicación del motivo. Si Code Guardian mejora el resultado del trabajo, solo lo muestra la medición comparativa, y esta todavía no está disponible para la 17.3. Encontrará más información sobre el producto en la página del producto.

Preguntas frecuentes sobre Code Guardian 17.3

¿Tengo que ajustar algo para que la actualización surta efecto?

Para el funcionamiento básico, no. Tres excepciones figuran más arriba: los nuevos informes de autorización para migraciones, la línea de configuración para los dos gates activables y la versión de Codex.

¿Por qué se bloquea mi comando de migración después de la actualización?

Probablemente a su informe de autorización le falta la línea FREIGABE-FUER, o el tipo de comando no figura en ella. Las instrucciones de más arriba muestran cómo volver a crearlo.

¿Se comprueba ahora menos?

Se impone menos. Las reglas de los doce cerrojos dados de baja siguen en el skill, pero una infracción ya no le detiene. El borrado, los secretos en el commit, el despliegue y la migración siguen bloqueando.

¿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 después actualizado Code Guardian se explica en provimedia.de/code-guardian/updates.

Fuentes

• Instrucciones de actualización publicadas de la versión 17.3, ediciones de Claude y de Codex (portal de clientes)
• Prueba de verificación de la versión 17.3 frente a la v17.2 (portal de clientes)

Actualizado: 02.10.2026