Code Guardian 17.7 : ce qui change pour vous

Si vous déployez via ssh avec des options, des variables d'environnement ou dans un sous-shell, Code Guardian vous arrête à partir de la 17.6. C'est le changement que vous remarquerez le plus vite. Par ailleurs, à partir de la deuxième saisie d'une session, Code Guardian affiche environ 80 % de texte propre en moins, et le nouveau skill leitstand montre d'un coup d'œil toutes les sessions Claude Code de votre machine.

Ce panorama couvre la 17.4 (dans le portail client depuis le 04.10.2026), la 17.6 (depuis le 07.10.2026) et la 17.7 (depuis le 08.10.2026). Une version 17.5 n'a pas été publiée.

Ce que vous devriez faire maintenant :

• Avez-vous jusqu'ici déployé via ssh, avec des options, des variables d'environnement, un utilitaire placé devant, dans un sous-shell ou dans un bloc de texte transmis à ssh ? Alors le verrou de déploiement vous arrête à partir de la 17.6. Rédigez le rapport de validation et relancez la commande, comme pour tout autre déploiement.
• Votre dossier de hooks contient-il encore des fichiers des douze verrous que la 17.6 a retirés du paquet ? La mise à jour les nomme. Vous n'avez rien à faire, et vous pouvez les supprimer sans risque.
• Avez-vous défini le paramètre CG_STOP_AUFSCHUB dans la sortie de Claude ? Il n'a plus d'effet à partir de la 17.6.
• Vous êtes-vous appuyé sur l'ancienne limite de 900 lignes au total ? Elle ne s'applique plus comme valeur par défaut. Si vous voulez la conserver, définissez-la explicitement par option ou dans le fichier de projet.
• Mettez-vous à jour en exécution sans surveillance (claude -p) ? Le verrou de suppression peut y arrêter l'installateur. Lancez-le dans le terminal : bash install.sh. Sous Codex, l'installateur s'appelle install-codex.sh.
• Travaillez-vous sous Windows, avez-vous cloné Code Guardian avec Git et y avez-vous défini core.autocrlf=true ? Alors clonez une nouvelle fois et installez depuis le clone tout neuf. Sauvegardez d'abord vos modifications. Si vous utilisez le ZIP du portail client, vous n'êtes pas concerné.
• Voulez-vous aussi voir le quota dans le Leitstand ? Alors raccordez votre propre ligne d'état. La ligne correspondante figure dans le skill.

Qu'est-ce que le Leitstand ?

Le Leitstand est nouveau depuis la 17.6. C'est un petit service accessible uniquement sur votre machine. Il affiche dans le navigateur, d'un seul coup d'œil, toutes les sessions Claude Code de cette machine :

• quelle session travaille et laquelle vous attend,
• laquelle est bloquée sur un outil,
• laquelle a une décision en suspens, avec la question et les réponses possibles,
• la consommation de la dernière heure par projet,
• une analyse de la destination des tokens : par session et par type de sous-agent, par projet et par modèle, sur 24 heures ainsi que sur 7, 30 et 365 jours.

Si vous raccordez votre ligne d'état, vous voyez en plus la limite de 5 heures et la limite hebdomadaire, avec une projection jusqu'à la réinitialisation. Le Leitstand s'ouvre avec /leitstand ou avec python3 ~/.claude/skills/leitstand/tools/leitstand.py oeffnen, sous Windows avec py. L'accès est protégé par une clé que l'agent n'affiche jamais.

Le Leitstand ne fait que lire. Il ne termine, n'écrit dans ni ne modifie aucune session, et il ne consomme aucun token. Sous macOS, il ne démarre automatiquement que si vous l'activez expressément.

Ce que l'affichage peut montrer à tort :

• Après un changement de compte, le quota affiche encore le compte précédent, jusqu'à ce que Claude Code écrive la ligne d'état suivante.
• Une session terminée peut apparaître comme active si le système a entre-temps réattribué son numéro de processus.
• Le Leitstand reconnaît les questions à la dernière ligne d'une réponse. Une question au milieu du texte apparaît comme terminée, un bloc de code final avec un point d'interrogation apparaît comme une question.
• Une boîte de dialogue ouverte dans la session est affichée comme « en attente », pas comme une alerte.

Le Leitstand n'existe que pour Claude Code, pas dans le paquet Codex.

Pour vous, cela signifie : si vous avez plusieurs sessions ouvertes en parallèle, vous voyez en un seul endroit où l'on vous attend. L'affichage est une aide à l'orientation, il ne remplace pas un coup d'œil dans la session.

De combien de texte en moins Code Guardian s'affiche-t-il désormais ?

Depuis la 17.6, les indications plus longues que Code Guardian affiche pour une saisie ne s'affichent en entier que la première fois dans une session. Ensuite, un rappel d'une seule ligne suit. Les règles restent les mêmes. Cela concerne :

• le guide vers le mode adapté,
• la liste des tâches,
• les indications sur les interfaces, les analyses de données et l'analyse des causes,
• les propositions de configuration.

Si le contenu d'une indication change, par exemple le nombre de tâches ouvertes, elle réapparaît en entier. Après un compactage, tout réapparaît une fois en entier.

Mesuré : à partir de la deuxième saisie d'une session, Code Guardian affiche environ 80 % de texte propre en moins, soit 383 caractères au lieu de 2 048 par saisie suivante dans le réglage standard. Selon votre façon de travailler, cela représente environ 1 à 10 % de l'ensemble des tokens d'une session. Les 80 % portent sur le texte que Code Guardian affiche lui-même, pas sur l'ensemble de votre session. Le paquet Codex reste inchangé sur ce point.

Pour vous, cela signifie : les indications restent, elles ne se répètent simplement plus en entier. L'impact dans votre quotidien dépend de votre façon de travailler.

Quelles corrections de sécurité contiennent les versions 17.4, 17.6 et 17.7 ?

Ce sont des corrections, pas de nouvelles fonctions. Elles ferment des écritures dans lesquelles une commande passait jusqu'ici entre les verrous. Les quatre verrous centraux contrôlent la suppression, la migration de base de données, le déploiement et les secrets dans le commit.

Dans la 17.7

• Commande suivante cachée dans des chaînes de caractères. Certaines écritures avec des caractères spéciaux dans des chaînes pouvaient cacher une commande suivante aux verrous. Ces écritures sont désormais reconnues, dans les verrous centraux, dont la suppression, la migration de base de données et le déploiement. Si une telle chaîne n'est pas fermée, Code Guardian demande confirmation. Vous n'avez rien à faire.

Dans la 17.6

• Python ne charge plus de modules depuis le dossier du projet. Lorsqu'un verrou lançait un court programme Python, un fichier du projet pouvait jusqu'ici prendre la place d'un module fourni.
• Les variables placées devant ne masquent plus aucune commande. Lorsqu'une affectation de variable précédait une commande, les quatre verrous centraux pouvaient, dans certaines écritures, ne pas la voir. Ils la contrôlent désormais aussi sans l'affectation, et le résultat le plus strict l'emporte.
• Déploiement via ssh sous des formes détournées. Une mise à jour du serveur passait jusqu'ici sans rapport de validation si des options, des variables d'environnement ou un utilitaire placé devant accompagnaient la commande, ou si elle figurait dans un sous-shell ou un bloc de texte transmis. Le verrou traite désormais ces formes comme la forme simple et exige le rapport. Restent libres les commandes git en lecture via ssh (statut, journal, aide) et un bloc de texte simplement écrit dans un fichier ou affiché.
• Un redémarrage sur le serveur demande confirmation. Lorsqu'une commande lancée via ssh sur une machine distante y redémarre un service, l'arrête ou y relance des conteneurs, Code Guardian demande désormais confirmation. Rien n'est refusé pour autant. Un rapport de validation récent pour un déploiement dans la même commande valide aussi le redémarrage. Un simple rechargement de la configuration et les mêmes commandes sur votre propre machine restent libres. Sous Codex, cette demande de confirmation n'est pas active.
• Clés dans un dépôt tout juste créé. Jusqu'ici, le contrôle de commit ignorait un dossier sans dépôt Git, même si la même commande créait d'abord le dépôt avec git init ou git clone et commitait aussitôt. Un fichier .env ou un fichier de clés copié dedans pouvait ainsi atterrir dans le premier commit sans confirmation. Désormais, Code Guardian contrôle un tel dossier comme s'il s'agissait déjà d'un dépôt vide, et refuse une clé. Cela vaut aussi pour un nouveau dépôt dans un sous-dossier d'un projet existant, masqué par le .gitignore de ce dernier.

Dans la 17.4

• Protection en écriture de la configuration sous Windows. Elle reconnaît désormais toutes les écritures de chemins. Jusqu'ici, une exécution sans surveillance pouvait modifier sous Windows les réglages de Claude Code, dans une certaine écriture, sans être arrêtée. La faille existait déjà dans la 17.3.
• Suppression. Le verrou de suppression lit désormais aussi un script shell lancé lorsque le lancement se trouve derrière un mot-clé du shell, par exemple dans une condition ou une boucle. Il détermine aussi correctement l'emplacement d'un script après un changement de répertoire qui peut échouer ou ne s'exécuter que sous condition. Une boucle qui lance d'abord un script puis l'écrase dans son corps est refusée.
• Déploiement. Le verrou de déploiement reconnaît les cibles distantes contenant des espaces, les options placées après la cible distante, d'autres utilitaires placés devant et, sous Windows, un lecteur comme source. Il reconnaît aussi un fichier secret sous ces écritures.
• Migration. Le verrou de migration exige désormais un rapport de validation même sans commande de schéma. Cela concerne :
  • les interventions via des fonctions auxiliaires de la base de données (terminer des sessions, positionner des séquences),
  • la création d'une table à partir d'une requête,
  • les copies vers la base de données ou vers un fichier, voire un programme,
  • les sorties shell et programme des clients,
  • les insertions avec écrasement et les upserts.
  Le verrou ne lit que les commandes qui appellent un client de base de données. Les mêmes mots dans un filtre de test ou dans un message ne déclenchent rien. L'appel d'une procédure stockée donne lieu à une demande de confirmation, car son effet n'est pas lisible dans la commande, de même que l'écriture d'une requête dans un nouveau fichier sur le serveur de base de données. En exécution sans surveillance (claude -p), cette demande de confirmation agit comme un blocage.

Pour vous, cela signifie : certaines commandes qui passaient jusqu'ici inaperçues sont désormais arrêtées ou donnent lieu à une demande de confirmation. Nous ne prétendons pas que chaque écriture est ainsi couverte. Les corrections concernent des formes connues.

Quelles fausses alertes et quels refus peu clairs ont disparu ?

• Recommandation adaptée en exécution sans surveillance (17.4). Lorsqu'une exécution sans surveillance ou le pilote automatique lançait un script que le verrou de suppression ne peut pas lire, par exemple l'installateur lors de la mise à jour, le refus recommandait un commentaire d'exemption qui n'y fonctionne pas. Désormais, il indique la voie qui fonctionne : lancer le script dans le terminal, lors de la mise à jour bash install.sh.
• Description correcte pour ssh … bash -s < datei (17.4). Le refus affirmait « ne figure dans aucun fichier ». Il décrit désormais le cas correctement.
• Le verrou de déploiement indique le nom (17.4). S'il ne reconnaît un script que par son nom, il indique ce nom comme motif.
• Les refus indiquent l'endroit (17.6). Lorsque le verrou de migration refuse une commande à cause d'un script lancé, le refus indique désormais toujours le script et les lignes qui ont été déterminantes. Cela vaut aussi pour des passages situés tout au fond du script et pour des passages qui ne résultent que de plusieurs lignes.
• Volontairement plus souple (17.4). Une commande qui lance un script dans la condition d'un while ou d'un until (ou derrière !, do, then, else, elif) puis l'écrit ensuite dans la même commande était refusée, même si le script ne peut pas être modifié au démarrage. Cette forme étroite est désormais libre. Le sens inverse est plus strict, voir les corrections ci-dessus.
• Plus de plantage dans le verrou des secrets (17.4). En cas de mot mal délimité par des guillemets dans un appel git, il ne plante plus mais demande confirmation. Un réglage git dont le contenu n'est connu qu'à l'exécution donne lieu lui aussi à une demande de confirmation.
• Moins de fausses corrections dans l'analyse (17.4). L'analyse de la friction d'une session ne compte plus les messages de l'environnement (retours de sous-agents, d'autres sessions, messages système) comme une correction de votre part.

Pour vous, cela signifie : là où un refus vous égarait jusqu'ici, il indique désormais l'endroit ou la voie qui fonctionne.

Que change-t-il pour les verrous, le démarrage de session et Windows ?

Douze verrous sont retirés du paquet (17.6)

Ce sont les verrous qui n'étaient plus enregistrés depuis le noyau de verrous de la 17.3 et ne contrôlaient donc plus rien. Cela ne change rien au comportement, car ils étaient déjà désactivés dans la 17.3. Le nombre de hooks du paquet passe ainsi de 27 à 15. Ce n'est pas un nouvel affaiblissement par rapport à la 17.3. Sont retirés :

• les contrôles des motifs glob et des installations de paquets avant une commande,
• la clôture de périmètre (contrôle et définition),
• le contrôle des clés d'accès dans les adresses,
• le contrôle de caractérisation,
• six contrôles en fin de réponse (revue à froid, constats non étayés, liste des tâches, rétrospective, preuves et mission).

Une mise à jour supprime leurs entrées de la configuration, mais ne supprime pas d'elle-même les anciens fichiers de ces verrous. La mise à jour nomme ces fichiers restés en place.

Démarrage de session

• Complet même sans jq (17.6). Sur les machines sans l'utilitaire jq, le démarrage de session restait jusqu'ici muet. Votre agent ne recevait aucune consigne de travail au début de la session, et cela passait inaperçu. Désormais, Python reprend cette tâche. L'accueil n'affiche plus sous « Nouveau dans » que la version actuelle.
• Autres changements (17.4). Si un démarrage de session échoue, la session suivante le signale exactement une fois. Lorsqu'un projet se trouve sur l'installation elle-même, le démarrage de session n'y compare plus chaque fichier avec lui-même. Après un compactage, l'indication de prompt affiche de nouveau l'intake complet et non plus seulement une ligne courte.
• Outil de rapport (17.4). Il avertit lorsqu'un rapport de déploiement ou de migration n'est pas ignoré par git, et indique la ligne adaptée pour le .gitignore.

Windows

• Vue d'ensemble des tâches (17.7). Une URL dans la liste des tâches ne fait plus se figer ni échouer la vue d'ensemble des tâches. En cas d'encodage de caractères étranger et de dossier verrouillé pour le prochain numéro de tâche, elle indique la cause au lieu d'une erreur Python. Le démarrage de session n'affiche plus de faux zéros en cas d'encodage étranger.
• Autres changements (17.4). Un jq installé via winget est désormais considéré comme présent. Un clone Git crée tous les fichiers avec des fins de ligne uniformes, voir la liste ci-dessus.

Limite de taille de fichier (17.6)

Elle compte désormais les lignes de code, y compris le code intégré dans des chaînes et des heredocs. Les commentaires, docstrings et lignes vides ne comptent plus. L'ancienne limite de 900 lignes au total disparaît comme valeur par défaut. Celui qui la définit expressément (option ou fichier de projet) la conserve comme limite plus stricte volontaire.

Pour vous, cela signifie : le comportement des verrous retirés ne change pas. Si vous en avez encore dans le dossier de hooks, faites le ménage.

Que change-t-il pour les agents de contrôle, l'analyse de données et les sessions multiples ?

Agents de contrôle avec délai (17.6)

Les 14 agents de contrôle respectent désormais un délai : 40 minutes ou 120 appels d'outils, selon ce qui est atteint en premier. Les agents sans shell ne comptent que les appels d'outils, et une mission peut fixer le délai autrement. Lorsque le délai est atteint, ils livrent un résultat partiel avec la liste de ce qui n'a pas été vérifié, au lieu de continuer sans sortie. Un agent de contrôle interrompu laisse depuis la 17.4 un état intermédiaire.

Le contrôleur de diff et les contrôleurs de couches écrivent en outre leurs constats dans une section propre de leur fichier de preuves, afin qu'ils arrivent mot pour mot dans le rapport. Le contrôleur de diff traite chaque affirmation du diff comme non étayée tant qu'il ne l'a pas vérifiée.

Si un sous-agent s'interrompt à cause d'une limite d'utilisation, Code Guardian demande à votre agent de vous avertir immédiatement et de reprendre après la réinitialisation, au lieu de redémarrer en silence ou de changer de modèle.

Pour vous, cela signifie : un agent de contrôle ne continue plus sans sortie, et vous voyez ce qu'il n'a pas vérifié.

Analyse de données, council et e-mail (17.6)

• Dans une analyse de données, chaque filtre est d'abord vérifié sur un résultat connu avant que son résultat ne compte. Un zéro issu d'un filtre non vérifié est considéré comme non étayé.
• Dans le council, avant l'évaluation mutuelle, on consigne quelle lettre correspond à quel conseiller.
• Sous pilote automatique, aucun e-mail ne part pour l'instant. Il est préparé, consigné dans son texte intégral, signalé dans le rapport final sous « En attente de validation » et attend votre décision.

Travail avec plusieurs sessions (17.6)

Le rôle d'une session d'orchestrateur est conservé au-delà d'un compactage. Après /compact, elle reçoit une courte note sur la manière de poursuivre. Les arbres de travail sont de préférence ouverts via l'outil de passage à un arbre de travail. Lorsqu'une étape attend une autre session, elle figure dans le plan de l'orchestrateur et part comme nouvelle mission dès que la condition préalable est remplie.

Outils (17.4)

La détection de Vitest trouve les configurations en .mts et .cts ainsi que les projets sans fichier de configuration. Un projet vide ou un fichier de test sans test reste rouge.

Quelles limites restent ouvertes ?

Nous les nommons au lieu de les taire :

• Scripts sur le serveur. Ce qui figure dans la ligne de commande elle-même est reconnu. Un déroulement enregistré sur le serveur dans un fichier de script et appelé là-bas n'est pas visible d'ici.
• Changement d'utilisateur sur le serveur. Il n'est pas encore lu sous toutes ses formes. Nous y travaillons.
• Enveloppes de commande. Elles ne sont pas encore évaluées complètement.
• Variables placées devant dans les scripts. À l'intérieur des scripts appelés, cette détection ne s'applique pas encore. Cela suivra dans une prochaine mise à jour.
• Très gros dossiers sans dépôt. Si une commande crée un dépôt, par exemple dans le répertoire personnel ou à la racine, le contrôle peut aller jusqu'à sa limite de temps puis demande confirmation. Dans ce cas, il ne valide jamais en silence. Comme on ne peut pas déterminer à l'avance dans quel dossier le dépôt sera créé, Code Guardian contrôle chaque dossier possible. Si l'un d'eux contient un fichier de clés qui ne serait pas du tout commité, un refus inutile peut en résulter. Le sens le plus strict est choisi volontairement.
• Dépôt tout neuf dans une enveloppe shell. Lorsque la commande se trouve dans une enveloppe shell supplémentaire, le nouveau contrôle des clés dans les dépôts tout juste créés ne s'applique pas encore. Le travail se poursuit.
• Windows sans terminal. Pour les points d'entrée programmatiques (SDK, serveur MCP, GitHub Action), Code Guardian ne reconnaît pas sous Windows si un humain est tout de même devant le terminal. La validation du plan par l'humain est alors supprimée. Les verrous de blocage, la protection en écriture et l'audit restent actifs. Nous corrigerons cela dans l'une des prochaines mises à jour.
• Interruption au démarrage de session sous Windows. Si seul le programme de démarrage extérieur d'un démarrage de session échoue, l'interruption n'est pas signalée.
• Verrou de migration. L'écriture additive (INSERT, LOAD DATA) est libre. Le verrou ne fait pas de différence entre la base de données locale et celle de production, hormis les bases de données de test de Code Guardian. Un INSERT peut avoir des effets externes via des triggers ou des files d'attente.
• Suppression désigne des fichiers et des répertoires, pas des enregistrements qu'un programme supprime. Toute exécution à distance qui modifie un état en cours n'est pas reconnue.

En outre, la version 17.3 avait annoncé pour la 17.4 quatre points qui n'étaient pas encore contenus dans la sortie Claude de la 17.4 et restaient prévus :

• Les fichiers des verrous désenregistrés restaient dans le paquet dans la 17.4. La version 17.6 les a retirés.
• Le verrou de migration n'affecte pas encore, dans certaines formes de commande, une migration ou son rapport de validation à la bonne racine de projet dans tous les cas.
• Le verrou de déploiement ne reconnaît pas encore un script de transfert dans tous les cas.
• design-beweis mesure, dans certains cas, trop tôt les pages qui ne construisent leur contenu qu'après le chargement, et n'évalue pas le contraste lorsque le jeu de couleurs est commutable.

Pour les trois derniers points, les textes de publication des versions 17.6 et 17.7 n'indiquent aucun nouvel état.

Pour vous, cela signifie : pour les déploiements, les migrations et les commandes de suppression, ne comptez pas uniquement sur le fait qu'un verrou se déclenche. Pour les scripts et les formes de commande inhabituelles, vérifiez vous-même s'il est intervenu.

Que change-t-il pour les utilisateurs de Codex ?

Les corrections de sécurité, le délai des agents de contrôle, les modifications des textes de refus et l'analyse de données correspondent pour l'essentiel à la sortie Claude. Ce qui est différent :

• Le Leitstand n'est pas dans le paquet Codex.
• La demande de confirmation lors d'un redémarrage via ssh n'est pas active sous Codex, car toute demande de confirmation y deviendrait un blocage.
• Là où la sortie Claude demande confirmation, Codex arrête la commande : pour une chaîne non fermée (17.7), pour une procédure stockée et pour un mot mal délimité par des guillemets dans le verrou des secrets.
• Dans le paquet Codex, l'installateur s'appelle install-codex.sh. Les refus le recommandent pour un lancement dans le terminal.
• La correction de sécurité Windows de la 17.4 concerne là-bas les réglages de Codex, lorsque le répertoire de configuration et la cible étaient écrits différemment.
• La limite Windows pour la validation du plan concerne, sous Codex, les sessions dont les validations sont désactivées.
• Au lieu des quatre points ouverts de la 17.3, la sortie Codex en cite trois : l'affectation à la racine de projet pour le verrou de migration, le script de transfert pour le verrou de déploiement et, avec un CODEX_HOME propre, des indications de réparation sur ~/.codex ainsi que l'absence d'analyse des incidents en fin de session.
• Le texte Codex ne mentionne ni le démarrage de session sans jq ni les modifications pour plusieurs sessions.

Pour vous, cela signifie : sous Codex, une demande de confirmation de la sortie Claude devient en règle générale une commande arrêtée. La demande de confirmation lors d'un redémarrage via ssh y est entièrement supprimée ; de telles commandes s'exécutent sous Codex sans confirmation. Lancez les scripts comme l'installateur dans le terminal.

Comment la 17.7 a-t-elle été vérifiée, et que dit la mesure comparative ?

La 17.7 est passée par la batterie de contrôle avant sa publication. Le tableau montre les chiffres comparés à la 17.3.

Pour mise en perspective : huit niveaux ont été ajoutés, un a disparu. Les niveaux qui contrôlent les deux directions d'erreur des verrous se sont déroulés sans échec : les cas contrôlés ont été arrêtés à juste titre ou laissés passer à juste titre.

Les chiffres du paquet de la 17.7 sont recomptés sur le zip : 5 modes, 7 gates, 15 hooks, 22 détecteurs, 27 skills et 14 agents de contrôle. Dans la 17.3, il y avait 27 hooks et 26 skills. Le nombre de hooks plus faible s'explique par les douze verrous retirés, le skill supplémentaire est le Leitstand.

Pour la 17.7, il n'existe pas de nouvelle mesure comparative. La dernière valable date du 28.09.2026 pour la v17.2, et aucune n'est venue s'ajouter depuis l'article sur la 17.3. Nous ne citons donc aucun chiffre et n'en inventons pas.

Conclusion : la batterie de contrôle s'est déroulée sans échec, cinq niveaux ont été ignorés, autant que pour la 17.3. Seule la mesure comparative montre si Code Guardian améliore le résultat du travail, et elle n'existe pas pour la 17.7. Vous trouverez plus d'informations sur le produit sur la page produit. L'article précédent se lit ici : Code Guardian 17.3 : ce qui change pour vous.

Questions fréquentes sur Code Guardian 17.7

Dois-je configurer quelque chose pour que la mise à jour prenne effet ?

Pour le fonctionnement de base, non. Les corrections des verrous prennent effet d'elles-mêmes après la mise à jour. Vous n'avez à agir que dans les cas qui figurent dans la liste ci-dessus.

Le Leitstand me coûte-t-il des tokens ?

Non. Il ne fait que lire et ne consomme aucun token. Il ne termine, n'écrit dans ni ne modifie aucune session.

Contrôle-t-on désormais moins ?

Pour l'essentiel non, mais volontairement plus souplement à deux endroits. Depuis la 17.4, le verrou de suppression laisse libre une forme étroite, dans laquelle un script démarre dans la condition d'un while ou d'un until puis est écrit ensuite dans la même commande. Et la limite de 900 lignes au total ne s'applique plus comme valeur par défaut depuis la 17.6.

Les douze verrous retirés ne contrôlaient plus rien depuis la 17.3. Continuent de bloquer la suppression, la migration de base de données, le déploiement et les secrets dans le commit, et ils voient depuis les versions 17.4, 17.6 et 17.7 davantage d'écritures qu'auparavant. Les limites ouvertes figurent ci-dessus.

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

• Guides de mise à jour publiés des versions 17.4, 17.6 et 17.7, sortie Claude et Codex (portail client)
• Preuves de contrôle des versions 17.3 et 17.7 (portail client)

Date : 08.10.2026