Code Guardian 17.9 : ce qui change pour vous

Avec Code Guardian 17.8 et 17.9, vous remarquerez surtout que les verrous lisent des commandes qu'ils laissaient passer jusqu'ici : des scripts derrière des redirections, des commandes dans d'autres enveloppes shell et des scripts envoyés via l'entrée standard par ssh à un shell sur une machine distante. Certaines commandes qui passaient jusqu'ici peuvent donc être désormais arrêtées.

Par ailleurs, Code Guardian vérifie une fois par projet si des réglages de Claude Code ou de Codex consomment beaucoup de contexte, et le Council conserve ses verdicts pendant 24 heures.

Cet aperçu couvre la 17.8 (dans le portail client depuis le 10.10.2026) et la 17.9 (depuis le 12.10.2026). L'article consacré à la version précédente se trouve ici : Code Guardian 17.7 : nouveautés.

Ce que vous devriez faire maintenant :

• Si le contrôle des jetons (à partir de la 17.8) trouve quelque chose au premier démarrage de session après la mise à jour, répondez à sa question : ajuster ou laisser tel quel. Rien n'est modifié sans votre « oui » explicite (version Claude). Dans la version Codex, il se contente d'indiquer les lignes concernées, et vous les ajustez à la main ou les laissez.
• Si un script derrière une redirection est arrêté (17.8), traitez-le comme n'importe quel autre script arrêté : la marche à suivre est la même.
• Si vous travaillez avec des enveloppes shell profondément imbriquées, attendez-vous à davantage de questions ou d'arrêts : lorsqu'une enveloppe est imbriquée plus profondément que Code Guardian ne la lit, il pose la question (version Claude) ou arrête la commande (version Codex).
• Vous lancez des sessions par programme sous Windows avec Git Bash ? Depuis la 17.9, Code Guardian y reconnaît correctement le terminal, et la validation du plan par un humain n'est plus supprimée à tort. S'il ne peut pas lire les processus parents, il suppose la présence d'un terminal.
• Si vous utilisez le Council, vous trouverez les verdicts complets des dernières 24 heures dans le registre des décisions de votre projet.

Quels verrous lisent désormais davantage ?

En bref : si vous emballez des commandes, les externalisez dans des scripts derrière des redirections ou les envoyez vers une machine distante, vous serez désormais contrôlé plus souvent. Dans le détail :

Scripts derrière des redirections (17.8)

Lorsqu'une redirection précédait l'appel d'un script, ou que le script arrivait par l'entrée standard, le verrou de suppression et le verrou de migration ne lisaient pas son contenu jusqu'ici. Ils le lisent désormais aussi dans ces syntaxes. Des commandes qui passaient jusqu'ici peuvent donc être arrêtées ; la marche à suivre est la même que pour tout autre script.

Davantage d'enveloppes shell (17.9)

Une commande emballée dans un appel shell supplémentaire est désormais lue plus souvent. Cela vaut pour les enveloppes avec des options supplémentaires avant ou après l'option de démarrage, pour une seconde enveloppe à l'intérieur de la première, pour des shells plus rares et pour la syntaxe de guillemets que les outils produisent lors du quoting automatique.

Le verrou de suppression est le principal concerné, et en partie aussi la migration et le déploiement. De même, le verrou de suppression lit désormais les commandes contenues dans les chaînes de caractères d'un interpréteur de scripts, qui y lancent à leur tour un shell. Cette lacune existait déjà en 17.8.

Commandes distantes ssh qui exécutent leur entrée comme un programme (17.9)

Lorsqu'une commande envoie un script par l'entrée standard, via ssh, à un shell ou à un interpréteur de scripts sur une machine distante, y compris derrière sudo, le verrou de suppression lit désormais ce contenu comme une commande. Les données qui ne sont que stockées ou lues à l'autre bout restent des données.

Répertoires racine, home et /tmp (17.9)

Le verrou laissait passer certaines syntaxes avec lesquelles une commande de suppression visait le répertoire racine, le répertoire home ou /tmp lui-même. Il les arrête désormais.

Texte transmis par xargs à un client de base de données (17.9)

Le texte transmis par xargs à un client de base de données est désormais considéré comme du SQL et vérifié, y compris dans des syntaxes qui passaient jusqu'ici.

Déploiement avec redémarrage dans la même commande (17.8, version Claude)

Un rapport de validation récent autorisait jusqu'ici aussi un redémarrage ou un arrêt de service sur la machine distante lorsqu'il figurait dans la même commande. Désormais, le déploiement reste autorisé, et pour toute intervention sur l'état en cours d'exécution de la machine distante, Code Guardian pose la question. Les appels distants en lecture seule et les commandes locales ne déclenchent pas cette question. Dans une exécution sans humain, cela représente un arrêt de plus.

Ce que cela signifie pour vous : Il s'agit de correctifs : les verrous lisent des syntaxes qu'ils ignoraient jusqu'ici, et le déploiement avec redémarrage s'accompagne d'une question supplémentaire. Certaines commandes qui passaient jusqu'ici inaperçues sont donc désormais arrêtées ou font l'objet d'une question.

Que vérifie le nouveau contrôle des jetons ? (version Claude)

Depuis la 17.8, Code Guardian vérifie, une fois par projet au premier démarrage de session après la mise à jour, si des réglages de Claude Code consomment beaucoup de contexte : le niveau de réflexion, la fenêtre de compactage et la taille des fichiers d'instructions. S'il trouve quelque chose, il affiche les lignes concernées et vous pose une question : ajuster ou laisser tel quel.

• Rien n'est modifié sans votre « oui » explicite, uniquement l'endroit indiqué, avec une sauvegarde et un retour en arrière indiqué.
• Les fichiers d'instructions ne sont jamais modifiés.
• Aucun contrôle n'a lieu dans les exécutions sans humain ; la question est alors posée lors d'une session ultérieure.

Ce que le contrôle ne fait pas figure plus bas, dans les limites. Son comportement dans la version Codex est décrit dans la section destinée aux utilisateurs de Codex.

Ce que cela signifie pour vous : C'est vous qui décidez. Sans votre « oui », votre configuration reste telle qu'elle est.

Qu'en est-il du Council et du poste de pilotage ?

Registre des décisions du Council (17.9)

Le Council peut désormais retrouver une décision antérieure, même après la compaction d'une longue session. Le skill associé llm-council :

• inscrit chaque verdict complet dans un registre des décisions propre au projet (.code-guardian-evidence/council-entscheidbuch.md),
• le lit au début de la délibération suivante,
• laisse tomber les entrées de plus de 24 heures,
• ne montre jamais le registre au regard extérieur indépendant,
• n'inscrit pas les délibérations interrompues.

Poste de pilotage (17.9, version Claude)

Le nœud de quota affiche la semaine lorsqu'aucune fenêtre de 5 heures n'est signalée, au lieu de « aucun flux de quota ». Sans session active, il n'est plus tronqué en haut, et sa couleur suit le même calcul que la carte voisine.

Qu'est-ce qui change sous Windows et pour le journal ?

• Détection du terminal sous Git Bash (17.9). Jusqu'ici, toute exécution y était considérée comme « sans terminal », parce que l'interrogation des processus parents échoue. Lors d'un lancement par programme, la validation du plan par un humain était ainsi supprimée. Désormais, Code Guardian lit les processus parents par une seconde voie ; s'il ne peut pas les lire, il suppose la présence d'un terminal.
• Orchestrateur de sessions sous Windows (17.9, version Claude). Il ne parvenait jamais à déterminer sa propre session et refusait toute attribution ; le démarrage de session y comptait une session libre de trop peu. Désormais, la session propre est déterminée via la liste des processus de Windows.
• Journal fail-open lors de sessions démarrant simultanément (17.9). Lorsque plusieurs sessions démarraient presque en même temps, des lignes pouvaient apparaître en double dans le journal ou une transmission restée en suspens pouvait être écrasée. Désormais, un démarrage ne recueille que les transmissions de démarrages terminés et n'en écrase aucune.
• Journal fail-open documenté (17.8). Le README et le guide de mise à jour expliquent désormais le journal des cas où un verrou n'a pas pu effectuer son contrôle faute d'un outil, avec l'indication de l'endroit où migrent les lignes plus anciennes. Sous Windows, le démarrage de session signale spécifiquement lorsqu'un verrou n'a pas pu convertir des chemins (version Claude).

Quels autres correctifs et améliorations ?

• Le verrou de secrets de commit s'arrête moins souvent à tort lors des merges (17.8). Une valeur qui figurait déjà dans le même fichier dans l'un des deux états, par exemple après un renommage du nom de la clé, est désormais considérée comme connue. Une valeur nouvellement ajoutée, une valeur provenant d'un autre fichier et toute clé privée continuent d'arrêter le commit, de même que tout doute.
• Texte de refus du verrou de suppression corrigé (17.8). Le texte citait /var/tmp comme emplacement jetable, alors que le verrou ne l'a jamais traité ainsi. Le comportement ne change pas ; le texte ne le promet simplement plus.
• La preuve de design mesure plus précisément les pages réelles (17.8). Pour les pages qui ne sont entièrement construites que dans le navigateur, la sonde d'état mesure après le chargement et après la fin des transitions. Pour le texte, c'est l'endroit dessiné le plus faible qui compte, de sorte qu'une partie illisible dans un lien se remarque.
• Preuve de design : libellés et jeux de couleurs (17.8). Pour les cases à cocher et les boutons radio, le libellé visible et cliquable compte dans la taille de la cible. Les pages avec jeu de couleurs clair et sombre et arrière-plan opaque sont mesurées au lieu d'être interrompues. Le nombre de constats peut ainsi évoluer dans les deux sens.
• Détecteur de slop dans les monorepos (17.8). Il lit les listes de paquets entre le fichier et la racine et ne signale plus les dépendances propres d'un sous-paquet comme un import inventé ; une liste de paquets endommagée n'interrompt plus l'exécution.
• Dossier de tâche et compteur de friction (17.8). Un dossier de tâche dont le nom contient une date ne reçoit plus cette date en double. Le compteur de friction ne compte plus comme friction un test rouge avant l'exécution verte ni une recherche sans résultat ; ses chiffres ne sont donc pas comparables avec les rétrospectives plus anciennes.
• Externaliser la vue d'ensemble des tâches (17.8, nouveau, uniquement sur appel). La vue d'ensemble des tâches peut externaliser dans des fichiers de détail les textes des points terminés et dormants, afin que la liste reste petite.

Ce que cela signifie pour vous : Moins d'arrêts inutiles lors du merge, et les constats de la preuve de design peuvent changer. Ne comparez pas les chiffres du compteur de friction avec ceux des rétrospectives plus anciennes.

Quelles limites restent ouvertes ?

Nous les nommons au lieu de les taire :

• Entrée standard (17.8). Les verrous de suppression et de migration ne lisent pas encore quelques syntaxes rares utilisant l'entrée standard.
• Commandes distantes ssh (17.9). Le verrou de suppression ne lit pas encore un shell de connexion sans commande propre ni les shells dans des conteneurs.
• Registre des décisions du Council (17.9). Un texte qui ressemble à une valeur d'accès n'est pas inscrit ; une valeur inoffensive peut elle aussi être rejetée à cette occasion.
• Contrôle des jetons (17.8). Les valeurs proposées sont notre réglage par défaut, et non une mesure faite sur votre projet. Il ne contrôle pas les réglages imposés par l'administration (version Claude).
• Orchestrateur sous Windows (17.9, version Claude). Si un maillon de la chaîne manque, la session propre reste inconnue et l'orchestrateur n'attribue rien.

Ce que cela signifie pour vous : Pour les commandes de suppression et de migration dans ces syntaxes, ne comptez pas uniquement sur le déclenchement d'un verrou.

Qu'est-ce qui change pour les utilisateurs de Codex ?

Le registre des décisions du Council, la lecture élargie des enveloppes shell, les commandes distantes ssh, le verrou de suppression pour les répertoires racine, home et /tmp, le verrou de migration avec xargs, le journal fail-open et la détection du terminal sous Git Bash figurent dans les deux versions. Il en va de même, depuis la 17.8, pour les scripts derrière des redirections, le verrou de secrets de commit, le texte de refus corrigé, la preuve de design et les outils.

Différences qui peuvent être établies à partir des textes :

• Enveloppe trop profonde (17.9). Lorsqu'une enveloppe shell est imbriquée plus profondément que Code Guardian ne la lit, la version Codex arrête la commande au lieu de poser la question.
• Contrôle des jetons (17.8). La version Codex contrôle le niveau de réflexion, le seuil de compactage et la taille du fichier d'instructions, et indique les lignes concernées. Elle ne modifie rien elle-même : vous ajustez le réglage à la main ou vous le laissez. Là aussi, les valeurs indicatives sont notre réglage par défaut, et aucun contrôle n'a lieu dans les exécutions sans humain.
• Absent du texte Codex. Le texte Codex ne mentionne ni l'orchestrateur de sessions sous Windows (17.9), ni le correctif du poste de pilotage (17.9), ni la question posée lors d'un déploiement avec redémarrage dans la même commande (17.8).
• Skills associés (17.8). La description de la version Codex mentionne désormais chaque skill associé livré, en une ligne.

Ce que cela signifie pour vous : Sous Codex, la décision et le travail manuel restent de votre côté pour le contrôle des jetons, et une enveloppe imbriquée trop profondément entraîne l'arrêt de la commande.

État de la mesure comparative : la dernière exécution valide, du 08.10.2026, mesure la v17.7 : en moyenne 5,7 avec contre 5,0 sans Code Guardian, p = 0,13, résultat « non décidable ». Il n'existe pas de mesure propre pour la 17.8 et la 17.9 ; à cette date, il y avait au total 9 comparaisons valides.

Vous trouverez plus d'informations sur le produit sur la page produit.

Questions fréquentes sur Code Guardian 17.8 et 17.9

Dois-je faire quelque chose après la mise à jour ?

Vous devez agir si le contrôle des jetons trouve quelque chose et pose une question (version Claude ; sous Codex, vous ajustez à la main les lignes indiquées), ainsi que là où une commande est arrêtée.

Le contrôle des jetons modifie-t-il mes réglages de lui-même ?

Non, voir plus haut : uniquement sur votre « oui » explicite, et pas du tout dans la version Codex.

Pourquoi une commande qui fonctionnait jusqu'ici est-elle arrêtée ?

Parce que les verrous lisent désormais des syntaxes qu'ils ignoraient auparavant, par exemple des scripts derrière des redirections ou des commandes dans d'autres enveloppes shell.

Où trouver les prérequis, les réglages et le paquet ?

Les prérequis et les réglages figurent dans la documentation technique. Le paquet se trouve dans le portail client. La manière dont Code Guardian reste ensuite à jour est expliquée sur provimedia.de/code-guardian/updates.

Sources

• Aperçus des modifications publiés (« Nouveautés ») des versions 17.8 et 17.9, versions Claude et Codex (portail client)

État : 12.10.2026