Code Guardian 17.3: Was sich für Sie ändert
Code Guardian 17.3 ist seit 02.10.2026 im Kundenportal. Nach dem Update werden Sie seltener unterbrochen, am Sitzungsende und bei gewöhnlichen Befehlen. Dafür sind zwölf Riegel abgemeldet: Ihre Prüfungen sind jetzt nur noch Arbeitsanweisung. Hier lesen Sie, welche Sperren jetzt Ihre Aufgabe sind und was Sie vor und nach dem Update tun sollten.
Was Sie jetzt tun sollten:
- Gehen Sie die Tabelle der abgemeldeten Sperren unten durch. Wo Sie sich auf eine verlassen haben, gehört die Prüfung jetzt in Ihren eigenen Ablauf. Welche davon bei Ihnen eingetragen waren, nennt die Ausgabe des Updates in der Zeile „REMOVED (Riegelkern, …)“.
- Nutzen Sie Freigabeberichte für Migrationen? Dann erstellen Sie alte Berichte neu, nach der Anleitung unten. Ein Bericht ohne die Zeile
FREIGABE-FUERgibt nichts mehr frei. - Brauchen Sie das Rechts-Gate oder das Datenauswertungs-Gate? Dann schalten Sie sie zu (Anleitung unten).
- Benutzen Sie Codex? Dann prüfen Sie vor dem Update mit
codex --version, ob Sie mindestens Fassung 0.150.0 haben.
Was ist der Riegelkern?
Ein Riegel ist eine Prüfung, die einen Befehl oder eine Aktion anhalten kann. Bisher hielten sehr viele davon an. In 17.3 sperren nur noch die Riegel mit echtem Schadenspotenzial.
- DESTRUCTIVE hält riskante Löschbefehle an.
- COMMIT-SECRET hält einen Commit an, in dem ein Geheimnis steckt.
- DEPLOY hält eine Auslieferung an, für die kein freigegebener Bericht vorliegt.
- MIGRATION hält Datenbankänderungen an, für die kein Freigabebericht vorliegt.
- Der Schreibschutz für unbeaufsichtigte Läufe ist eng gefasst. Er sperrt nur noch den Selbstschutz der Riegel und der Einstellungsdateien sowie das Schreiben von Zugangsdaten.
- Das DECISION GATE hält eine Optionsfrage nur noch im Autopilot an. Dort entscheidet der llm-council. Sonst gibt es nur einen Hinweis.
Unabhängig von den zwölf abgemeldeten Riegeln unten geben weitere Hooks, darunter Sitzungsstart und Prompt-Check, nur noch Hinweise.
Für Sie heißt das: Sie bekommen weniger Rückfragen und Absagen. Die vier Befehls-Riegel schützen Sie weiter vor Löschen, Geheimnissen im Commit, Auslieferung und Migration.
Welche Sperren sind jetzt Ihre Aufgabe?
Das ist eine Einschränkung, keine Verbesserung. Die Regeln stehen weiter im Skill, aber ein Verstoß hält Sie nicht mehr technisch an. Wer sich auf eine dieser Sperren verlassen hat, etwa darauf, dass eine neue Paket-Installation angehalten wird, muss die Prüfung jetzt selbst übernehmen. Das gilt auch für den Beleg des kalten Zweitlesers, also eines unabhängigen Prüfers, der Ihre Änderung ohne Vorwissen liest.
Der Scope-Zaun steht als eine Zeile, weil zu ihm zwei Dateien gehören (eine setzt den Umfang, eine sperrte Schreibzugriffe außerhalb).
| Prüfung | Was bisher anhielt | Was Sie jetzt selbst tun | Datei |
|---|---|---|---|
| Neue Abhängigkeiten | Das Hinzufügen oder pauschale Aktualisieren von Fremdpaketen (etwa composer require) ohne frischen, freigegebenen Bericht. | Prüfen Sie ein neues Paket selbst, bevor es in Ihr Projekt kommt. | dependency-gate-check |
| Dateimuster in Anführungszeichen | Befehle mit einem Dateimuster ohne Anführungszeichen, das für das Programm gedacht war (etwa grep --include=*.js). | Setzen Sie solche Muster selbst in Anführungszeichen. | glob-quoting-gate-check |
| Scope-Zaun | Schreibzugriffe auf Dateien außerhalb des Umfangs, den die Plan-Freigabe festgelegt hatte. | Ändern Sie nur Dateien, die der freigegebene Plan nennt. | scope-fence-check, scope-fence-setzen |
| Token im Query-String | Code, der serverseitig einen Zugangs-Token aus der Adresszeile liest. | Lesen Sie Token nur aus einem Header. | query-token-gate-check |
| Test vor dem Umbau | Der Umbau von Code in einem belegt ungetesteten Gebiet, solange kein Test das heutige Verhalten festhielt. | Schreiben Sie vor dem Umbau einen Test, der das heutige Verhalten festhält. | characterization-gate-check |
| Zweitleser am Sitzungsende | Der Abschluss nach Änderungen an Dateien der Sperrliste oder an mehr als 300 Zeilen ohne kalten Zweitleser. | Lassen Sie bei solchen Änderungen selbst einen unabhängigen Prüfer lesen. | kaltreview-gate-check |
| Behauptungen prüfen | Eine Antwort, die eine ungeprüfte Behauptung über das Systemverhalten in eine Handlung umsetzte. | Prüfen Sie eine Behauptung, bevor Sie darauf handeln. | befund-gate-check |
| Offene Schritte der Aufgabe | Das Sitzungsende, solange der Plan der Aufgabe noch offene Schritte trug. | Haken Sie offene Schritte vor dem Abschluss ab oder nennen Sie sie ausdrücklich. | todo-gate-check |
| Rückblick | Das Sitzungsende nach Schreibarbeit ohne belegten Aufgaben-Rückblick. | Machen Sie den Rückblick selbst am Ende der Aufgabe. | retro-gate-check |
| Belegzeilen | Eine Belegzeile, deren Zahlen nie aus einem Werkzeug stammten. | Übernehmen Sie Zahlen nur aus einem tatsächlich gelaufenen Werkzeug. | beleg-gate-check |
| Zusagen des Auftrags | Der Abschluss, solange eine Zusage oder ein Verbot aus dem Auftrag noch unbelegt war. | Prüfen Sie vor dem Abschluss, ob jede Zusage und jedes Verbot belegt ist. | auftrag-gate-check |
Das Update entfernt die Einträge dieser Riegel aus Ihrer settings.json. Einen gleichnamigen Hook in einem anderen Ordner, den Sie selbst eingetragen haben, lässt es stehen. Die Dateien der abgemeldeten Riegel bleiben in dieser Fassung im Paket und in ~/.claude/hooks/, laufen aber nicht mehr. Die Löschung ist für v17.4 vorgesehen.
Wie erstelle ich einen Freigabebericht für Migrationen neu?
Ein Freigabebericht gilt jetzt nur noch für die Befehlsarten, die seine Zeile FREIGABE-FUER: <arten> nennt. Das Werkzeug schreibt sie beim Neuerstellen mit der Vorgabe migrate. Ein alter Bericht hat die Zeile gar nicht und gibt deshalb nichts mehr frei.
Der Aufruf des Berichtswerkzeugs gate-report.py im Skill code-guardian lautet:
gate-report.py migration (--files F... | --git [--ref REF]) [--wurzel DIR] [--fuer ART[,ART]]
- Erstellen Sie den Bericht mit dem Werkzeug neu, entweder mit
--filesund den Migrationsdateien oder mit--git. - Soll er mehr als migrate freigeben, nennen Sie die Arten mit
--fuer, zum Beispiel--fuer migrate,seed. Erlaubt sind migrate, seed, rollback, fresh, refresh, reset, wipe und ddl. Zerstörende Arten geben Sie nur ausdrücklich an. - Prüfen Sie im fertigen Bericht, dass die Zeile
FREIGABE-FUERda ist und die gewünschten Arten nennt.
Welche Sicherheitskorrekturen enthält 17.3?
Das sind Korrekturen an den Riegeln, die weiter sperren. Befehle, die bisher ungeprüft durchliefen, werden jetzt geprüft.
- Ein Freigabebericht für eine Migration gab bisher jeden Migrationsbefehl derselben Projektwurzel frei, auch migrate:fresh und migrate:rollback. Jetzt gibt er nur die Arten frei, die in
FREIGABE-FUERstehen. Das merken Sie sofort, wenn Ihr Bericht alt ist. - Ein Löschbefehl in zwei bestimmten verschachtelten Schreibweisen lief am Lösch-Riegel vorbei. Beide prüft er jetzt.
- Wurde dem Berichtswerkzeug eine Angabe doppelt übergeben, fiel eine Migration still aus dem Bericht, und der Bericht stufte sie zu harmlos ein. Jetzt werden beide Angaben berücksichtigt. Alte Berichte erstellen Sie ohnehin neu (siehe oben).
Wie schalte ich das Rechts-Gate und das Datenauswertungs-Gate zu?
Beide Gates sind ab jetzt zuschaltbar und standardmäßig aus. Zum Einschalten tragen Sie diese Zeile in ~/.claude/code-guardian.conf ein:
riegel_zusatz = rechts, data-analytics
Danach führen Sie bash install.sh aus. Wollen Sie nur eines der beiden, nennen Sie nur dieses.
Für Sie heißt das: Wer Rechtstexte oder Datenauswertungen erstellt, schaltet die Gates zu. Bisher liefen beide mit; jetzt sind sie aus, bis Sie sie zuschalten.
Welche Grenzen bleiben offen?
Zuerst die Grenzen, die Ihren Ablauf betreffen:
- Migrations- und Auslieferungs-Riegel: Der Migrations-Riegel ordnet in einigen Befehlsformen und Schreibweisen eine Migration oder ihren Freigabebericht noch nicht in jedem Fall der richtigen Projektwurzel zu. Der Auslieferungs-Riegel erkennt ein Übertragungsskript bisher nur an bekannten Namen. Beides ist für v17.4 vorgesehen. Prüfen Sie bis dahin bei eigenen Skripten und ungewöhnlichen Befehlsformen selbst, ob der Riegel gegriffen hat.
- Freigabebericht: Er ist an Befehlsarten gebunden, nicht an eine bestimmte Migrationsdatei.
- Sicherheitskorrekturen: Sie betreffen bekannte Schreibweisen. Dass damit jede Form erfasst ist, behaupten wir nicht. Verlassen Sie sich bei Löschbefehlen nicht allein auf den Riegel.
- Prüf-Subagenten: Sie arbeiten im gemeinsamen Arbeitsbaum. Dass sie dort keine fremde, nicht eingecheckte Arbeit anfassen, ist in dieser Fassung eine Arbeitsanweisung. Sichern Sie nicht eingecheckte Arbeit vorher.
Und die Grenzen einzelner Prüfungen:
- Die Geheimnissuche erkennt bekannte Formen von Zugangsdaten in lesbarem Text und führt keine Datenflussanalyse aus. Bei einer Datei in einer Zweibyte-Kodierung (UTF-16) kann sie nur eingeschränkt prüfen.
- design-beweis misst Seiten, die ihren Inhalt erst nach dem Laden aufbauen, unter Umständen zu früh. Den Kontrast auf Seiten mit umschaltbarem Farbschema bewertet es nicht. Die Korrektur ist für v17.4 vorgesehen.
- Nur Codex: Mit einem eigenen CODEX_HOME verweisen einige Reparaturhinweise noch auf ~/.codex, und die Vorfalls-Auswertung am Sitzungsende bleibt dort aus. Die Korrektur ist für v17.4 vorgesehen.
Für Sie heißt das: Bei Migrationen und Auslieferungen gilt bis v17.4: Verlassen Sie sich nicht allein darauf, dass der Riegel anschlägt.
Was ist bei der Geheimnissuche und den Analyse-Prüfungen neu?
Beide sagen jetzt „nicht gemessen“ oder „nicht geprüft“, wo sie früher ein grünes Ergebnis gezeigt hätten.
- Die Geheimnissuche ordnet jede Datei genau einer Klasse zu und nennt mit Anzahl, was sie nicht durchsucht hat („nicht geprüft: …“).
- Bisher suchte sie nur in Dateien mit bekannter Endung. Eine PowerShell-Datei, eine .ini, eine .toml oder ein Dockerfile galten still als sauber. Jetzt werden sie durchsucht.
- Wurde nichts durchsucht, obwohl Dateien da waren, ist das Ergebnis nicht „sauber“. Fehlt python3, meldet die Suche „nicht geprüft“.
- Fehlt ein eingerichtetes Analyse-Werkzeug, stürzt es ab oder überschreitet es seine Frist, melden die Analyse-Prüfungen „nicht gemessen“. Die Frist stellen Sie mit CG_ANALYSE_FRIST ein. Die Vorgabe sind 900 Sekunden.
Ehrlich dazu: Eine Datei mit einem sehr langen Zeichenlauf in einer einzigen Zeile kann die Geheimnissuche von einigen Sekunden bis über eine halbe Minute kosten. Das Ergebnis bleibt vollständig.
Für Sie heißt das: Wo nicht geprüft wurde, zeigt das Ergebnis nicht mehr Grün, sondern sagt es.
Was passiert mit der Statuszeile?
Die Statuszeile ist entfernt. Bei vielen parallelen Sitzungen kostete sie spürbar Rechenzeit. Code Guardian trägt keine mehr ein, und ein Update baut die früher von uns eingetragene zurück:
- Eine kombinierte Zeile geht auf Ihr eigenes Kommando zurück.
- Eine eigene Statuszeile bleibt unverändert.
- Haben Sie unser früheres Skript anders eingebunden, als der Installer es je geschrieben hat, bleibt die Zeile mit einer Warnung stehen. Räumen Sie sie dann bei Bedarf selbst auf.
- Die alten Schalter --statuszeile=… und --statuszeile-kombinieren werden weiter angenommen und übergangen.
- Die gesicherte Kopie Ihrer früheren Statuszeile wird nicht gelöscht, wenn sie die einzige Kopie sein kann.
- Der Dashboard-Skill clistatus bleibt.
- Die orange Signalmarke, die zeigen sollte, dass ein Riegel eingegriffen hat, entfällt mit der Statuszeile. Ob ein Riegel eingreift, hängt nicht an der Statuszeile.
Für Sie heißt das: Hatten Sie eine eigene Statuszeile, ändert sich nichts. Hatten Sie unsere, baut das Update sie zurück. Nur eine Einbindung, die der Installer nie geschrieben hat, bleibt mit einer Warnung stehen.
Was ändert sich unter Windows und beim Sitzungsstart?
- Mit einem nativen jq.exe kam der Nullbefund-Hinweis bisher nie. Jetzt kommt er.
- Der Prompt-Check läuft schneller. Seine Textarbeit je Prompt geschieht in einem einzigen python3-Aufruf statt in vielen kleinen Prozessen.
- Hatte ein Riegel selbst eine Störung gemeldet, war der nächste Sitzungsstart spürbar langsamer, vor allem unter Windows. Die Auswertung des Störungsprotokolls startete viele kleine Prozesse und läuft jetzt in einem Durchgang. Die Meldung ist unverändert.
- Bricht die Auswertung ab, sagt der Sitzungsstart das in einer sichtbaren Zeile und lässt das Protokoll liegen. Früher schob er es still in die Historie.
Für Sie heißt das: Nach einer Riegel-Störung startet die nächste Sitzung unter Windows schneller, und ein Fehler bleibt nicht mehr unbemerkt.
Was ist bei Einstellungen, Werkzeugen und Dokumentation neu?
Der Installer übernimmt Ihre Wahl in code-guardian.conf jetzt auch, wenn die Datei schon existiert. Eine dokumentierte Einstellung, die dort noch fehlt, ergänzt er am Ende mit ihrer Vorgabe. Ihre Zeilen bleiben unverändert.
Bei den Werkzeugen gibt es kleinere Änderungen. jsqa-onboard schaltet den Playwright-Trace bei Fehlschlägen ein. Die Aufgabenliste prüft ihre Formregeln vor dem Schreiben. Der Skill session-orchestrator hat einen Auftragseingang mit Frist und legt für jede Sitzung einen eigenen Arbeitsbaum an. Die Dokumentation ist korrigiert: Veraltete Zahlen sind ersetzt, und Windows ist als unterstützte Plattform genannt.
Was ändert sich für Codex-Nutzer?
Die Geheimnissuche, die Analyse-Prüfungen, die Sicherheitskorrekturen, die Einstellungen und die schnellere Auswertung des Störungsprotokolls beim Sitzungsstart entsprechen der Claude-Ausgabe. Der jq.exe-Hinweis und der schnellere Prompt-Check gelten nur für Claude Code. Anders ist Folgendes:
- Neue Voraussetzung ist codex-cli 0.150.0 oder neuer. Das Update bricht ab, ohne etwas zu ändern, wenn codex nicht im PATH liegt oder älter ist. Prüfen Sie mit
codex --version. Aktualisieren können Sie etwa mitnpm install -g @openai/codex@latest. - Die abgemeldeten Riegel sind unter Codex nicht dieselben wie in der Tabelle oben. Nicht mehr eingehängt sind dort unter anderem der Airlock vor der ersten Dateiänderung, der Projektzaun, der Abhängigkeits-Riegel und alle Riegel am Sitzungsende. Ihre Regeln stehen weiter als Arbeitsanweisung in den Skills.
- Die Zusatz-Riegel für Rechtstexte und Datenauswertung lassen sich unter Codex in dieser Fassung nicht einschalten.
- Der Hinweis, den Codex bei jedem Prompt einblendet, nennt keine Werkzeuge mehr, die es nur in Claude Code gibt. Er verlangt stattdessen einen Plan mit update_plan und die Antwort des Menschen.
Für Sie heißt das: Prüfen Sie vor dem Update die Codex-Fassung. Das spart einen abgebrochenen Lauf.
Wie wurde 17.3 geprüft, und was sagt die Vergleichsmessung?
17.3 lief vor der Veröffentlichung durch die Prüfbatterie. Die Tabelle zeigt die Zahlen im Vergleich zu 17.2.
| Fassung | Ebenen | bestanden | fehlgeschlagen | übersprungen |
|---|---|---|---|---|
| v17.2 | 138 | 134 | 0 | 4 |
| v17.3 | 153 | 148 | 0 | 5 |
Zur Einordnung: 16 Ebenen sind neu hinzugekommen. Eine ist entfallen, die Ebene zur Statuszeile. Beide Fehlerrichtungen der Riegel bestanden vollständig: Sie schlagen zu Recht an, und sie lassen zu Recht durch, was erlaubt ist.
Seit dem Artikel zu 17.2 gibt es keine neue gültige Vergleichsmessung. Für 17.3 können wir deshalb keine Zahl nennen, und wir erfinden keine. Über alle gültigen Vergleiche von v16.116 bis 17.2 (8 Messungen) gilt weiter: 4 mit belegtem Unterschied, 3 nicht entscheidbar, 1 ohne belegten Unterschied. Einzelheiten stehen unter den Benchmarks.
Fazit: Die Prüfbatterie lief ohne Fehlschlag; fünf Ebenen wurden im Schnellmodus mit Grund übersprungen. Ob Code Guardian das Arbeitsergebnis verbessert, zeigt nur die Vergleichsmessung, und die liegt für 17.3 noch nicht vor. Mehr zum Produkt finden Sie auf der Produktseite.
Häufige Fragen zu Code Guardian 17.3
Muss ich etwas einstellen, damit das Update wirkt?
Für den Grundbetrieb nein. Drei Ausnahmen stehen oben: neue Freigabeberichte für Migrationen, die Konfigurationszeile für die beiden zuschaltbaren Gates und die Codex-Fassung.
Warum sperrt mein Migrationsbefehl nach dem Update?
Vermutlich fehlt Ihrem Freigabebericht die Zeile FREIGABE-FUER, oder die Befehlsart steht nicht darin. Die Anleitung oben zeigt, wie Sie ihn neu erstellen.
Wird jetzt weniger geprüft?
Es wird weniger erzwungen. Die Regeln der zwölf abgemeldeten Riegel stehen weiter im Skill, aber ein Verstoß hält Sie nicht mehr an. Löschen, Geheimnisse im Commit, Auslieferung und Migration sperren weiter.
Wo finde ich Voraussetzungen, Einstellungen und das Paket?
Voraussetzungen und Einstellungen stehen in der technischen Dokumentation. Das Paket liegt im Kundenportal. Wie sich Code Guardian danach aktuell hält, erklärt provimedia.de/code-guardian/updates.
Quellen
- Veröffentlichte Update-Anleitung der Fassung 17.3, Claude- und Codex-Ausgabe (Kundenportal)
- Prüfnachweis der Fassung 17.3 gegenüber v17.2 (Kundenportal)
- Vergleichsmessung: provimedia.de/code-guardian#benchmarks
Stand: 02.10.2026
Beitrag teilen
Bleiben Sie auf dem Laufenden
Erhalten Sie die neuesten Artikel, Insights und Branchen-Updates direkt in Ihr Postfach.
So bestimmen Sie selbst, was Google Ihnen zeigt
Google lässt Sie festlegen, welche Quellen in Ihren Suchergebnissen bevorzugt erscheinen: in den Schlagzeilen und in den KI-Antworten. Zwei Klicks, und Sie sehen die Seiten, denen Sie vertrauen.
provimedia.de zu meinen Quellen hinzufügenÄhnliche Beiträge
Weitere Artikel, die Sie interessieren könnten.
Code Guardian 17.2: Was sich für Sie ändert
Code Guardian 17.2 schließt mehrere Wege an den Riegeln vorbei, streicht Fehlalarme und macht die Prüfzeit unter Windows messbar. Die Testabdeckung zählt jetzt strenger, und die Vergleichsmessung zeigt: Ein Lauf ohne Unterschied ist kein Beleg, dass Code Guardian wirkt.
Wer haftet für KI-generierten Code? Was sich 2026 ändert
Software ist ab Dezember 2026 ausdrücklich ein Produkt im Sinne der Produkthaftung. Was das für Entwickler, Agenturen und Auftraggeber bedeutet.
Definition of Done für KI-Code: Belege statt Zusagen
Wenn Code in Minuten entsteht, verschiebt sich der Engpass auf die Frage, wann etwas fertig ist. Eine Definition of Done, die diesem Tempo standhält.
Prüfungen, die sich nicht überspringen lassen
Das Skill-Paket für Claude Code und OpenAI Codex: sieben Gates vor Deploy, Migration, neuer Abhängigkeit, Datenurteil, Befund, Optionsfrage und Rechtstext. Firmenlizenz, unbegrenzt viele Entwickler im Unternehmen.