Code Guardian 17.3: What Changes for You

Code Guardian 17.3 has been in the customer portal since 02.10.2026. After the update you will be interrupted less often, at the end of a session and on ordinary commands. In exchange, twelve gates are deregistered: their checks are now only working instructions. Here you can read which blocks are now your job and what you should do before and after the update.

What you should do now:

• Go through the table of deregistered blocks below. Where you relied on one, the check now belongs in your own workflow. The output of the update names the ones registered on your machine in the line “REMOVED (Riegelkern, …)”.
• Do you use approval reports for migrations? Then regenerate old reports, following the instructions below. A report without the line FREIGABE-FUER no longer approves anything.
• Do you need the legal gate or the data analysis gate? Then switch them on (instructions below).
• Do you use Codex? Then check with codex --version before the update that you have version 0.150.0 or later.

What is the gate core?

A gate is a check that can stop a command or an action. Until now, a great many of them did. In 17.3, only the gates with real potential for damage still block.

• DESTRUCTIVE stops risky delete commands.
• COMMIT-SECRET stops a commit that contains a secret.
• DEPLOY stops a release for which no approved report exists.
• MIGRATION stops database changes for which no approval report exists.
• The write protection for unattended runs is narrowly scoped. It now only blocks the self-protection of the gates and the settings files, as well as the writing of credentials.
• The DECISION GATE now stops an options question only in autopilot. There, the llm-council decides. Otherwise there is only a notice.

Independently of the twelve deregistered gates below, other hooks, including session start and prompt check, now only give notices.

What this means for you: You get fewer follow-up questions and refusals. The four command gates continue to protect you against deletion, secrets in a commit, release and migration.

Which blocks are now your responsibility?

This is a restriction, not an improvement. The rules remain in the skill, but a violation no longer stops you technically. Anyone who relied on one of these blocks, for example on a new package installation being stopped, now has to take over the check themselves. This also applies to the evidence of the cold second reader, that is, an independent reviewer who reads your change without any prior knowledge.

The scope fence appears as a single row because two files belong to it (one sets the scope, one blocked writes outside it).

The update removes the entries of these gates from your settings.json. A hook of the same name in another folder that you registered yourself is left in place. The files of the deregistered gates remain in the package and in ~/.claude/hooks/ in this version, but no longer run. Deletion is planned for v17.4.

How do I regenerate an approval report for migrations?

An approval report now applies only to the command types named in its line FREIGABE-FUER: <arten>. When regenerating, the tool writes it with the default migrate. An old report does not have the line at all and therefore no longer approves anything.

The call of the report tool gate-report.py in the code-guardian skill is:

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

1. Regenerate the report with the tool, either with --files and the migration files or with --git.
2. If it should approve more than migrate, name the types with --fuer, for example --fuer migrate,seed. Allowed are migrate, seed, rollback, fresh, refresh, reset, wipe and ddl. Specify destructive types only explicitly.
3. In the finished report, check that the line FREIGABE-FUER is present and names the types you want.

Which security fixes does 17.3 contain?

These are fixes to the gates that continue to block. Commands that previously passed unchecked are now checked.

• An approval report for a migration used to approve every migration command of the same project root, including migrate:fresh and migrate:rollback. Now it approves only the types listed in FREIGABE-FUER. You will notice this immediately if your report is old.
• A delete command in two specific nested notations slipped past the delete gate. It now checks both.
• If a value was passed to the report tool twice, a migration silently dropped out of the report, and the report rated it as too harmless. Now both values are taken into account. You regenerate old reports anyway (see above).

How do I switch on the legal gate and the data analysis gate?

Both gates can now be switched on and are off by default. To enable them, enter this line in ~/.claude/code-guardian.conf:

riegel_zusatz = rechts, data-analytics

Then run bash install.sh. If you only want one of the two, name only that one.

What this means for you: If you create legal texts or data analyses, switch the gates on. Until now both ran along; now they are off until you switch them on.

Which limits remain open?

First, the limits that affect your workflow:

• Migration and release gates: In some command forms and notations, the migration gate does not yet assign a migration or its approval report to the right project root in every case. The release gate so far recognizes a transfer script only by known names. Both are planned for v17.4. Until then, check yourself with your own scripts and unusual command forms whether the gate took effect.
• Approval report: It is tied to command types, not to a specific migration file.
• Security fixes: They cover known notations. We do not claim that this captures every form. Do not rely on the gate alone for delete commands.
• Review subagents: They work in the shared working tree. That they do not touch anyone else’s uncommitted work there is, in this version, a working instruction. Back up uncommitted work beforehand.

And the limits of individual checks:

• The secret scan recognizes known forms of credentials in readable text and performs no data flow analysis. For a file in a two-byte encoding (UTF-16), it can only check to a limited extent.
• design-beweis may measure pages that build their content only after loading too early. It does not assess contrast on pages with a switchable color scheme. The fix is planned for v17.4.
• Codex only: With a custom CODEX_HOME, some repair hints still point to ~/.codex, and the incident analysis at session end is skipped there. The fix is planned for v17.4.

What this means for you: For migrations and releases, the following applies until v17.4: Do not rely solely on the gate triggering.

What is new in the secret scan and the analysis checks?

Both now say “not measured” or “not checked” where they would previously have shown a green result.

• The secret scan assigns each file to exactly one class and names, with a count, what it did not search (“not checked: …”).
• Until now it only searched files with a known extension. A PowerShell file, an .ini, a .toml or a Dockerfile silently counted as clean. Now they are searched.
• If nothing was searched although files were present, the result is not “clean”. If python3 is missing, the scan reports “not checked”.
• If a configured analysis tool is missing, crashes or exceeds its time limit, the analysis checks report “not measured”. You set the time limit with CG_ANALYSE_FRIST. The default is 900 seconds.

To be honest about it: A file with a very long run of characters on a single line can cost the secret scan anywhere from a few seconds to over half a minute. The result remains complete.

What this means for you: Where nothing was checked, the result no longer shows green but says so.

What happens to the status line?

The status line has been removed. With many parallel sessions, it cost noticeable computing time. Code Guardian no longer registers one, and an update rolls back the one we registered earlier:

• A combined line reverts to your own command.
• A custom status line stays unchanged.
• If you integrated our earlier script in a way the installer never wrote, the line stays in place with a warning. In that case, clean it up yourself if needed.
• The old switches --statuszeile=… and --statuszeile-kombinieren are still accepted and ignored.
• The saved copy of your earlier status line is not deleted if it may be the only copy.
• The dashboard skill clistatus stays.
• The orange signal marker that was meant to show that a gate had intervened goes away with the status line. Whether a gate intervenes does not depend on the status line.

What this means for you: If you had your own status line, nothing changes. If you had ours, the update rolls it back. Only an integration that the installer never wrote stays in place with a warning.

What changes on Windows and at session start?

• With a native jq.exe, the null-finding notice never appeared until now. Now it does.
• The prompt check runs faster. Its text processing per prompt happens in a single python3 call instead of many small processes.
• If a gate had reported a fault itself, the next session start was noticeably slower, especially on Windows. The analysis of the fault log started many small processes and now runs in a single pass. The message is unchanged.
• If the analysis aborts, the session start says so in a visible line and leaves the log in place. Before, it silently moved it into the history.

What this means for you: After a gate fault, the next session on Windows starts faster, and an error no longer goes unnoticed.

What is new in settings, tools and documentation?

The installer now also applies your choices in code-guardian.conf when the file already exists. A documented setting that is still missing there is appended at the end with its default. Your lines remain unchanged.

There are smaller changes to the tools. jsqa-onboard switches on the Playwright trace for failures. The task list checks its form rules before writing. The session-orchestrator skill has a task inbox with a deadline and creates a separate working tree for each session. The documentation has been corrected: outdated figures are replaced, and Windows is named as a supported platform.

What changes for Codex users?

The secret scan, the analysis checks, the security fixes, the settings and the faster analysis of the fault log at session start match the Claude edition. The jq.exe notice and the faster prompt check apply only to Claude Code. The following is different:

• The new requirement is codex-cli 0.150.0 or later. The update aborts without changing anything if codex is not on the PATH or is older. Check with codex --version. You can update with, for example, npm install -g @openai/codex@latest.
• The deregistered gates under Codex are not the same as in the table above. No longer hooked in there are, among others, the airlock before the first file change, the project fence, the dependency gate and all gates at session end. Their rules remain as working instructions in the skills.
• The additional gates for legal texts and data analysis cannot be switched on under Codex in this version.
• The notice that Codex shows with every prompt no longer names tools that exist only in Claude Code. Instead, it asks for a plan with update_plan and the human’s answer.

What this means for you: Check the Codex version before the update. That saves an aborted run.

How was 17.3 tested, and what does the comparison measurement say?

Before publication, 17.3 went through the test battery. The table shows the figures compared with 17.2.

For context: 16 layers are new. One was dropped, the layer for the status line. Both error directions of the gates passed completely: they rightly trigger, and they rightly let through what is allowed.

Since the article on 17.2 there has been no new valid comparison measurement. For 17.3 we therefore cannot give a figure, and we do not invent one. Across all valid comparisons from v16.116 to 17.2 (8 measurements), the following still holds: 4 with a documented difference, 3 undecidable, 1 without a documented difference.

Conclusion: The test battery ran without a failure; five layers were skipped in quick mode with a stated reason. Whether Code Guardian improves the work result is shown only by the comparison measurement, and that is not yet available for 17.3. You can find more about the product on the product page.

Frequently asked questions about Code Guardian 17.3

Do I have to configure anything for the update to take effect?

Not for basic operation. Three exceptions are listed above: new approval reports for migrations, the configuration line for the two optional gates, and the Codex version.

Why does my migration command block after the update?

Most likely your approval report lacks the line FREIGABE-FUER, or the command type is not listed in it. The instructions above show how to regenerate it.

Is less being checked now?

Less is being enforced. The rules of the twelve deregistered gates remain in the skill, but a violation no longer stops you. Deletion, secrets in a commit, release and migration still block.

Where do I find requirements, settings and the package?

Requirements and settings are in the technical documentation. The package is in the customer portal. How Code Guardian keeps itself up to date afterwards is explained at provimedia.de/code-guardian/updates.

Sources

• Published update guide for version 17.3, Claude and Codex editions (customer portal)
• Test evidence for version 17.3 compared with v17.2 (customer portal)

As of: 02.10.2026