Code Guardian 17.7: qué cambia para usted

Quien despliega por ssh con opciones, variables de entorno o dentro de una subshell será detenido por Code Guardian a partir de la 17.6. Es el cambio que más probablemente note. Además, a partir de la segunda entrada de una sesión, Code Guardian inserta aproximadamente un 80 % menos de texto propio, y la nueva skill leitstand muestra de un vistazo todas las sesiones de Claude Code de su equipo.

Este resumen abarca la 17.4 (en el portal de clientes desde el 04.10.2026), la 17.6 (desde el 07.10.2026) y la 17.7 (desde el 08.10.2026). La versión 17.5 no se publicó.

Qué debería hacer ahora:

• ¿Ha desplegado hasta ahora por ssh con opciones, variables de entorno, un programa auxiliar antepuesto, una subshell o un bloque de texto pasado a ssh? Entonces, a partir de la 17.6, el cerrojo de despliegue le detiene. Redacte el informe de aprobación y ejecute de nuevo el comando, como en cualquier otro despliegue.
• ¿Quedan en su carpeta de hooks archivos de los doce cerrojos que la 17.6 ha retirado del paquete? La actualización los menciona. No tiene que hacer nada, y se pueden borrar sin riesgo.
• ¿Ha establecido en la edición para Claude el ajuste CG_STOP_AUFSCHUB? A partir de la 17.6 ya no surte efecto.
• ¿Se ha apoyado en el antiguo límite de 900 líneas totales? Ya no rige como valor predeterminado. Si desea conservarlo, establézcalo de forma expresa mediante el interruptor o en el archivo del proyecto.
• ¿Actualiza en ejecución desatendida (claude -p)? El cerrojo de borrado puede detener allí el instalador. Inícielo en el terminal: bash install.sh. En Codex el instalador se llama install-codex.sh.
• ¿Trabaja en Windows, ha clonado Code Guardian con Git y ha establecido allí core.autocrlf=true? Entonces clone de nuevo una vez e instale desde el clon recién creado. Guarde antes sus propios cambios. Quien use el ZIP del portal de clientes no se ve afectado.
• ¿Quiere ver también la cuota en el Leitstand? Entonces conecte su propia línea de estado. La línea necesaria figura en la skill.

¿Qué es el Leitstand?

El Leitstand (el panel de control de sesiones) es nuevo desde la 17.6. Es un pequeño servicio accesible únicamente desde su equipo. Muestra en el navegador, de un vistazo, todas las sesiones de Claude Code de ese equipo:

• qué sesión está trabajando y cuál le está esperando a usted,
• cuál está bloqueada en una herramienta,
• cuál tiene una decisión pendiente, con la pregunta y las posibles respuestas,
• el consumo de la última hora por proyecto,
• un análisis de adónde van los tokens: por sesión y tipo de subagente, por proyecto y modelo, a lo largo de 24 horas y de 7, 30 y 365 días.

Quien conecta su línea de estado ve además el límite de 5 horas y el límite semanal, con una proyección hasta el reinicio. El Leitstand se abre con /leitstand o con python3 ~/.claude/skills/leitstand/tools/leitstand.py oeffnen, en Windows con py. El acceso está protegido con una clave que el agente nunca muestra.

El Leitstand solo lee. No finaliza, no escribe en ninguna sesión ni la modifica, y no consume tokens. En macOS solo se inicia automáticamente si usted lo activa de forma expresa.

Qué puede mostrar mal la pantalla:

• Tras un cambio de cuenta, la cuota sigue mostrando la cuenta anterior hasta que Claude Code escribe la siguiente línea de estado.
• Una sesión terminada puede aparecer como activa si el sistema ha asignado entretanto su número de proceso a otro proceso.
• El Leitstand reconoce las preguntas pendientes por la última línea de una respuesta. Una pregunta en mitad del texto aparece como terminada, y un bloque de código final con signo de interrogación aparece como pregunta pendiente.
• Un diálogo abierto en la sesión se muestra como «espera», no como alarma.

El Leitstand solo existe para Claude Code, no en el paquete de Codex.

Para usted esto significa: quien tiene varias sesiones abiertas en paralelo ve en un solo lugar dónde le están esperando. La pantalla es una orientación, no sustituye a echar un vistazo a la sesión.

¿Cuánto menos texto inserta ahora Code Guardian?

Desde la 17.6, los avisos más largos que Code Guardian inserta ante una entrada solo aparecen completos la primera vez en una sesión. Después sigue un recordatorio de una sola línea. Las reglas siguen siendo las mismas. Se trata de:

• la guía hacia el modo adecuado,
• la lista de tareas,
• los avisos sobre interfaces, análisis de datos y análisis de causas,
• las ofertas de configuración.

Si cambia el contenido de un aviso, por ejemplo el número de tareas abiertas, vuelve a aparecer completo. Tras una compactación, todo aparece una vez completo.

Medido: a partir de la segunda entrada de una sesión, Code Guardian inserta aproximadamente un 80 % menos de texto propio, concretamente 383 caracteres en lugar de 2.048 por cada entrada posterior con la configuración estándar. Según la forma de trabajar, eso supone aproximadamente entre un 1 y un 10 % del total de tokens de una sesión. El 80 % se refiere al texto que inserta el propio Code Guardian, no a toda su sesión. El paquete de Codex permanece sin cambios en este punto.

Para usted esto significa: los avisos se mantienen, simplemente ya no se repiten con toda su extensión. Cuánto supone esto en su día a día depende de su forma de trabajar.

¿Qué correcciones de seguridad incluyen la 17.4, la 17.6 y la 17.7?

Son correcciones, no capacidades nuevas. Cierran formas de escritura con las que un comando esquivaba hasta ahora los cerrojos. Los cuatro cerrojos centrales controlan el borrado, la migración de bases de datos, el despliegue y los secretos en el commit.

En la 17.7

• Comando siguiente oculto en cadenas de texto. Determinadas formas de escritura con caracteres especiales en cadenas de texto podían ocultar a los cerrojos un comando posterior. Ahora estas formas se detectan en los cerrojos centrales, entre ellos el de borrado, el de migración de bases de datos y el de despliegue. Si una cadena de este tipo no está cerrada, Code Guardian pregunta. No tiene que hacer nada.

En la 17.6

• Python ya no carga módulos desde el directorio del proyecto. Cuando un cerrojo iniciaba un pequeño programa en Python, un archivo del proyecto podía ocupar hasta ahora el lugar de un módulo incluido en el paquete.
• Las variables antepuestas ya no ocultan un comando. Si delante de un comando había una asignación de variable, los cuatro cerrojos centrales podían pasar por alto el comando en determinadas formas de escritura. Ahora lo revisan además sin la asignación, y vale el resultado más estricto.
• Despliegue por ssh en formas de rodeo. Actualizar el servidor pasaba hasta ahora sin informe de aprobación si al comando se le añadían opciones, variables de entorno o un programa auxiliar antepuesto, o si estaba dentro de una subshell o de un bloque de texto pasado. El cerrojo trata ahora estas formas como la forma simple y exige el informe. Siguen libres los comandos git de lectura por ssh (estado, registro, ayuda) y un bloque de texto que solo se escribe en un archivo o se muestra.
• Un reinicio en el servidor provoca una pregunta. Si un comando reinicia o detiene un servicio en un equipo remoto por ssh, o vuelve a levantar allí contenedores, Code Guardian pregunta ahora. No se rechaza nada. Un informe de aprobación reciente para un despliegue en el mismo comando autoriza también el reinicio. Una simple recarga de la configuración y los mismos comandos en su propio equipo siguen libres. En Codex esta pregunta no está activa.
• Claves en un repositorio recién creado. Hasta ahora, la comprobación del commit omitía una carpeta sin repositorio Git, incluso cuando el mismo comando crea primero el repositorio con git init o git clone y hace commit directamente. Un archivo .env que estuviera allí, o un archivo de claves copiado dentro, podía acabar así en el primer commit sin preguntar. Ahora Code Guardian comprueba una carpeta así como si ya fuera un repositorio vacío y rechaza una clave. Esto vale también para un repositorio nuevo en una subcarpeta de un proyecto existente que el .gitignore de este oculta.

En la 17.4

• Protección contra escritura de la configuración en Windows. Ahora reconoce todas las formas de escribir una ruta. Hasta ahora, una ejecución desatendida podía modificar en Windows los ajustes de Claude Code con una forma de escritura concreta sin ser detenida. La laguna ya existía en la 17.3.
• Borrado. El cerrojo de borrado lee ahora un script de shell iniciado también cuando el inicio está detrás de una palabra clave de la shell, por ejemplo en una condición o un bucle. También determina correctamente la ubicación de un script tras un cambio de directorio que puede fallar o ejecutarse solo de forma condicional. Se rechaza un bucle que primero inicia un script y luego lo sobrescribe en su cuerpo.
• Despliegue. El cerrojo de despliegue reconoce destinos remotos con espacios, opciones después del destino remoto, más programas auxiliares antepuestos y, en Windows, una unidad como origen. También reconoce un archivo secreto en estas formas de escritura.
• Migración. El cerrojo de migración exige ahora un informe de gate también sin comando de esquema. Esto afecta a:
  • las intervenciones mediante funciones auxiliares de la base de datos (finalizar sesiones, establecer secuencias),
  • la creación de una tabla a partir de una consulta,
  • las copias a la base de datos o a un archivo o programa,
  • las salidas de shell y de programa de los clientes,
  • las inserciones con sobrescritura y los upserts.
  El cerrojo solo lee comandos que invocan a un cliente de base de datos. Las mismas palabras en un filtro de pruebas o en un mensaje no activan nada. La llamada a un procedimiento almacenado provoca una pregunta, porque su efecto no se puede leer en el comando, igual que la escritura de una consulta en un archivo nuevo en el servidor de la base de datos. En la ejecución desatendida (claude -p) esta pregunta actúa como un bloqueo.

Para usted esto significa: algunos comandos que hasta ahora pasaban inadvertidos se detienen o provocan una pregunta. No afirmamos que con ello quede cubierta cualquier forma de escritura. Las correcciones se refieren a formas conocidas.

¿Qué falsas alarmas y negativas poco claras han desaparecido?

• Recomendación adecuada en la ejecución desatendida (17.4). Cuando una ejecución desatendida o el piloto automático iniciaba un script que el cerrojo de borrado no podía leer, por ejemplo el instalador durante la actualización, la negativa recomendaba un comentario de exención que allí no surte efecto. Ahora indica el camino que sí funciona: iniciar el script en el terminal y, en la actualización, bash install.sh.
• Descripción correcta en ssh … bash -s < datei (17.4). La negativa afirmaba «no consta en ningún archivo». Ahora describe el caso correctamente.
• El cerrojo de despliegue indica el nombre (17.4). Cuando reconoce un script solo por su nombre, lo indica como motivo.
• Las negativas indican el lugar (17.6). Cuando el cerrojo de migración rechaza un comando por un script iniciado, la negativa indica ahora siempre el script y las líneas que fueron decisivas. Esto vale también para pasajes muy al final del script y para pasajes que solo resultan de varias líneas.
• Deliberadamente más suave (17.4). Un comando que inicia un script en la condición de while o until (o tras !, do, then, else, elif) y luego lo escribe en el mismo comando se rechazaba, aunque el script no pudiera estar modificado en el momento del inicio. Esta forma estrecha queda ahora libre. En sentido contrario es más estricto, véanse las correcciones anteriores.
• Sin fallo en el cerrojo de secretos (17.4). Ante una palabra con comillas poco claras en una llamada a git, ya no falla, sino que pregunta. También se pregunta por un ajuste de git cuyo contenido solo se conoce en tiempo de ejecución.
• Menos correcciones falsas en el análisis (17.4). El análisis de la fricción de una sesión ya no cuenta como corrección suya los mensajes del entorno (respuestas de subagentes, de otras sesiones, mensajes del sistema).

Para usted esto significa: donde antes una negativa le inducía a error, ahora indica el lugar o el camino que funciona.

¿Qué cambia en los cerrojos, el inicio de sesión y Windows?

Doce cerrojos se retiran del paquete (17.6)

Son los cerrojos que desde el núcleo de cerrojos de la 17.3 ya no estaban registrados y, por tanto, ya no comprobaban nada. Esto no cambia el comportamiento, porque ya estaban desactivados en la 17.3. El número de hooks del paquete baja así de 27 a 15. No es un debilitamiento nuevo respecto a la 17.3. Se han retirado:

• las comprobaciones de patrones glob y de instalaciones de paquetes antes de un comando,
• la valla de alcance (comprobación y establecimiento),
• la comprobación de claves de acceso en direcciones,
• la comprobación de caracterización,
• seis comprobaciones al final de una respuesta (revisión en frío, hallazgos sin evidencia, lista de tareas, retrospectiva, evidencias y encargo).

Una actualización elimina sus entradas de la configuración, pero no borra por sí sola los archivos antiguos de estos cerrojos. La actualización menciona esos archivos que quedan.

Inicio de sesión

• Completo también sin jq (17.6). En equipos sin el programa auxiliar jq, el inicio de sesión permanecía hasta ahora mudo. Su agente no recibía instrucciones de trabajo al comienzo de la sesión, y no se notaba en ningún sitio. Ahora Python asume esta tarea. El saludo muestra en «Novedades de» solo la versión actual.
• Otros cambios (17.4). Si un inicio de sesión se interrumpe, la siguiente sesión lo comunica exactamente una vez. Si un proyecto está sobre la propia instalación, el inicio de sesión ya no compara allí cada archivo consigo mismo. Tras una compactación, el aviso del prompt vuelve a mostrar el intake completo en lugar de una sola línea breve.
• Herramienta de informes (17.4). Avisa cuando git no ignora un informe de despliegue o de migración e indica la línea adecuada para el .gitignore.

Windows

• Resumen de tareas (17.7). Una URL en la lista de tareas ya no deja colgado ni interrumpe el resumen de tareas. Ante una codificación de caracteres ajena y ante una carpeta bloqueada para el siguiente número de tarea, indica el motivo en lugar de un error de Python. El inicio de sesión ya no muestra ceros falsos con una codificación ajena.
• Otros cambios (17.4). Un jq instalado mediante winget se considera ahora presente. Un clon de Git crea todos los archivos con finales de línea uniformes, véase la lista anterior.

Límite de tamaño de archivo (17.6)

Ahora cuenta líneas de código, también el código incrustado en cadenas y heredocs. Los comentarios, los docstrings y las líneas vacías ya no cuentan. El antiguo límite de 900 líneas totales deja de ser un valor predeterminado. Quien lo establezca de forma expresa (interruptor o archivo del proyecto) lo conserva como límite más estricto voluntario.

Para usted esto significa: el comportamiento de los cerrojos retirados no cambia. Quien aún los tenga en la carpeta de hooks, que haga limpieza.

¿Qué cambia en los agentes de revisión, el análisis de datos y las sesiones múltiples?

Agentes de revisión con plazo (17.6)

Los 14 agentes de revisión respetan ahora un plazo: 40 minutos o 120 llamadas a herramientas, lo que se alcance primero. Los agentes sin shell cuentan solo las llamadas a herramientas, y un encargo puede fijar el plazo de otra manera. Cuando se alcanza el plazo, entregan un resultado parcial con una lista de lo que no se ha revisado, en lugar de seguir ejecutándose sin salida. Un agente de revisión que se cancela deja desde la 17.4 un estado intermedio.

El revisor de diffs y los revisores de capas escriben además sus hallazgos como sección propia en su archivo de evidencias, para que lleguen textualmente al informe. El revisor de diffs trata cada afirmación del diff como no probada hasta que la ha comprobado.

Si un subagente se interrumpe por un límite de uso, Code Guardian indica a su agente que le avise de inmediato y continúe tras el restablecimiento, en lugar de reiniciar en silencio o cambiar de modelo.

Para usted esto significa: un agente de revisión ya no sigue ejecutándose sin salida, y usted ve lo que no ha revisado.

Análisis de datos, council y correo (17.6)

• En un análisis de datos, cada filtro se comprueba primero con un acierto conocido antes de que cuente su resultado. Un cero procedente de un filtro sin comprobar se considera no probado.
• En el council, antes de la evaluación mutua se deja constancia de qué letra corresponde a qué asesor.
• Con el piloto automático no sale por ahora ningún correo. Se prepara, se registra con su texto íntegro, se comunica en el informe final bajo «Espera aprobación» y queda a la espera de usted.

Trabajo con varias sesiones (17.6)

El rol de una sesión orquestadora se conserva a través de una compactación. Tras /compact recibe una breve nota sobre cómo continuar. Los árboles de trabajo se abren preferentemente mediante la herramienta para cambiar a un árbol de trabajo. Si un paso espera a otra sesión, figura en el plan del orquestador y sale como nuevo encargo en cuanto se cumple la condición previa.

Herramientas (17.4)

La detección de Vitest encuentra configuraciones con .mts y .cts, así como proyectos sin archivo de configuración. Un proyecto vacío o un archivo de pruebas sin pruebas sigue en rojo.

¿Qué límites siguen abiertos?

Los mencionamos en lugar de ocultarlos:

• Scripts en el servidor. Se detecta lo que figura en la propia línea de comandos. Un flujo de trabajo guardado en un archivo de script en el servidor y llamado allí no es visible desde aquí.
• Cambio de usuario en el servidor. Todavía no se lee en todas sus formas. Estamos trabajando en ello.
• Envoltorios de comandos. Todavía no se evalúan por completo.
• Variables antepuestas en scripts. Dentro de los scripts invocados, esta detección todavía no rige. Llegará en una actualización posterior.
• Carpetas muy grandes sin repositorio. Si un comando crea un repositorio, por ejemplo en el directorio personal o en el raíz, la comprobación puede tardar hasta su límite de tiempo y luego pregunta. En ese caso nunca autoriza en silencio. Como no se puede determinar de antemano en qué carpeta se creará el repositorio, Code Guardian comprueba todas las posibles. Si en alguna de ellas hay un archivo de claves que en realidad no se incluiría en el commit, puede producirse un rechazo innecesario. Se ha elegido deliberadamente la dirección más estricta.
• Repositorio nuevo en un envoltorio de shell. Si el comando está en otro envoltorio de shell, la nueva comprobación de claves en repositorios recién creados todavía no rige. Se sigue trabajando en ello.
• Windows sin terminal. En puntos de entrada programáticos (SDK, servidor MCP, GitHub Action), Code Guardian no detecta en Windows si, pese a ello, hay una persona ante el terminal. Entonces se omite la aprobación del plan por parte de la persona. Los cerrojos de bloqueo, la protección contra escritura y la auditoría siguen activos. Lo corregiremos en una de las próximas actualizaciones.
• Interrupción en el inicio de sesión en Windows. Si solo se interrumpe el programa de arranque externo de un inicio de sesión, la interrupción no se comunica.
• Cerrojo de migración. La escritura aditiva (INSERT, LOAD DATA) es libre. El cerrojo no distingue entre la base de datos local y la de producción, salvo las bases de datos de prueba de Code Guardian. Un INSERT puede tener efectos externos a través de triggers o colas.
• Borrado se refiere a archivos y directorios, no a registros que borra un programa. No se detecta toda ejecución remota que modifique el estado en curso.

Además, la versión 17.3 había anunciado para la 17.4 cuatro puntos que aún no estaban incluidos en la edición para Claude de la 17.4 y quedaron previstos:

• Los archivos de los cerrojos dados de baja seguían en el paquete en la 17.4. La versión 17.6 los ha retirado.
• El cerrojo de migración asigna en algunas formas de comando una migración o su informe de aprobación todavía no siempre a la raíz de proyecto correcta.
• El cerrojo de despliegue todavía no reconoce en todos los casos un script de transferencia.
• design-beweis mide páginas que construyen su contenido solo después de cargar, en ocasiones demasiado pronto, y no evalúa el contraste con un esquema de color conmutable.

Sobre los tres últimos puntos, los textos de publicación de la 17.6 y la 17.7 no indican ningún estado nuevo.

Para usted esto significa: en despliegues, migraciones y comandos de borrado, no se fíe únicamente de que un cerrojo reaccione. En scripts y formas de comando inusuales, compruebe usted mismo si ha actuado.

¿Qué cambia para los usuarios de Codex?

Las correcciones de seguridad, el plazo de los agentes de revisión, los cambios en los textos de negativa y el análisis de datos coinciden en lo esencial con la edición para Claude. Es distinto lo siguiente:

• El Leitstand no está en el paquete de Codex.
• La pregunta ante un reinicio por ssh no está activa en Codex, porque allí cada pregunta se convertiría en un bloqueo.
• Donde la edición para Claude pregunta, Codex detiene el comando: ante una cadena de texto no cerrada (17.7), ante un procedimiento almacenado y ante una palabra con comillas poco claras en el cerrojo de secretos.
• En el paquete de Codex, el instalador se llama install-codex.sh. Las negativas lo recomiendan para iniciarlo en el terminal.
• La corrección de seguridad de Windows de la 17.4 afecta allí a los ajustes de Codex cuando el directorio de configuración y el destino estaban escritos de forma distinta.
• El límite de Windows en la aprobación del plan afecta en Codex a las sesiones con aprobaciones desactivadas.
• En lugar de los cuatro puntos abiertos de la 17.3, la edición para Codex menciona tres: la asignación a la raíz del proyecto en el cerrojo de migración, el script de transferencia en el cerrojo de despliegue y, con un CODEX_HOME propio, las indicaciones de reparación sobre ~/.codex, así como la falta de análisis de incidencias al final de la sesión.
• El texto de Codex no menciona ni el inicio de sesión sin jq ni los cambios para varias sesiones.

Para usted esto significa: en Codex, una pregunta de la edición para Claude suele convertirse en un comando detenido. La pregunta ante el reinicio por ssh desaparece allí por completo; en Codex esos comandos se ejecutan sin preguntar. Inicie scripts como el instalador en el terminal.

¿Cómo se verificó la 17.7 y qué dice la medición comparativa?

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

Para situarlo: se han añadido ocho niveles y ha desaparecido uno. Los niveles que comprueban ambas direcciones de error de los cerrojos se ejecutaron sin fallos: los casos comprobados se detuvieron con razón o se dejaron pasar con razón.

Las cifras del paquete de la 17.7 están recontadas sobre el zip: 5 modos, 7 gates, 15 hooks, 22 detectores, 27 skills y 14 agentes de revisión. En la 17.3 eran 27 hooks y 26 skills. El menor número de hooks se explica por los doce cerrojos retirados; la skill adicional es el Leitstand.

Para la 17.7 no hay una nueva medición comparativa. La última válida es la de la v17.2, del 28.09.2026, y desde el artículo sobre la 17.3 no se ha añadido ninguna. Por eso no indicamos ninguna cifra y no inventamos ninguna.

Conclusión: la batería de pruebas se ejecutó sin fallos; se omitieron cinco niveles, tantos como en la 17.3. Si Code Guardian mejora el resultado del trabajo solo lo muestra la medición comparativa, y para la 17.7 no está disponible. Encontrará más información sobre el producto en la página del producto. El artículo anterior puede leerlo en Code Guardian 17.3: qué cambia para usted.

Preguntas frecuentes sobre Code Guardian 17.7

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

Para el funcionamiento básico, no. Las correcciones en los cerrojos surten efecto por sí solas tras la actualización. Solo tiene que actuar en los casos que figuran en la lista anterior.

¿Me cuesta tokens el Leitstand?

No. Solo lee y no consume tokens. No finaliza, no escribe en ninguna sesión ni la modifica.

¿Se comprueba ahora menos?

En lo esencial no, aunque en dos puntos es deliberadamente más suave. Desde la 17.4, el cerrojo de borrado deja libre una forma estrecha en la que un script se inicia en la condición de while o until y luego se escribe en el mismo comando. Y desde la 17.6, el límite de 900 líneas totales ya no rige como valor predeterminado.

Los doce cerrojos retirados ya no comprobaban nada desde la 17.3. Siguen bloqueando el borrado, la migración de bases de datos, el despliegue y los secretos en el commit, y desde la 17.4, la 17.6 y la 17.7 ven más formas de escritura que antes. Los límites abiertos figuran más arriba.

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

Fuentes

• Guías de actualización publicadas de las versiones 17.4, 17.6 y 17.7, ediciones para Claude y para Codex (portal de clientes)
• Pruebas de verificación de las versiones 17.3 y 17.7 (portal de clientes)

Fecha: 08.10.2026