Code Guardian 17.9: What Changes for You

With Code Guardian 17.8 and 17.9, the change you are most likely to notice is that the gates read commands they previously missed: scripts behind redirections, commands inside additional shell wrappers, and scripts that are sent via standard input to a shell on a remote machine over ssh. Some commands that used to pass can therefore now be stopped.

In addition, Code Guardian now checks once per project whether Claude Code or Codex settings cost a lot of context, and the council remembers its verdicts for 24 hours.

This overview covers 17.8 (in the customer portal since 10 October 2026) and 17.9 (since 12 October 2026). You can find the article on the previous version at Code Guardian 17.7: What's New.

What you should do now:

• If the token check (from 17.8) finds something at the first session start after the update, answer its question: adjust or leave as is. Something is changed only on your explicit yes (Claude edition). In the Codex edition, it only names the lines, and you either adjust them by hand or leave them.
• If a script behind a redirection is stopped (17.8), treat it like any other stopped script: the way forward is the same.
• If you work with deeply nested shell wrappers, expect more questions or stops: if a wrapper is nested deeper than Code Guardian reads, it asks (Claude edition) or stops the command (Codex edition).
• Do you start sessions programmatically on Windows with Git Bash? Since 17.9, Code Guardian recognizes the terminal there correctly, and the plan approval by a human is no longer skipped by mistake. If it cannot read the parent processes, it assumes a terminal.
• If you use the council, you will find the complete verdicts of the last 24 hours in your project's decision log.

Which gates read more now?

In short: anyone who wraps commands, moves them into scripts behind redirections, or sends them to a remote machine will now be checked more often. In detail:

Scripts behind redirections (17.8)

If a redirection came before a script call, or if the script arrived via standard input, the delete gate and the migration gate previously did not read its contents. Now they read it in these notations as well. Commands that used to pass can therefore now be stopped; the way forward is the same as for any other script.

More shell wrappers (17.9)

A command packed into another shell call is now read more often. This applies to wrappers with extra switches before or after the start switch, to a second wrapper inside the first, to less common shells, and to the quoting notation that tools produce when they quote automatically.

The delete gate is affected most, and the migration and deploy gates in part. Likewise, the delete gate now reads commands in the strings of a script interpreter that only start a shell there. This gap already existed in 17.8.

Remote ssh commands that execute their input as a program (17.9)

If a command sends a script via standard input over ssh to a shell or script interpreter on a remote machine, even behind sudo, the delete gate now reads that content as a command. Data that is merely stored or read on the other side remains data.

Root, home, and /tmp directories (17.9)

The gate let through some notations with which a delete command hit the root directory, the home directory, or /tmp itself. It now stops them.

Text passed through xargs into a database client (17.9)

Text that goes through xargs into a database client is now treated as SQL and checked, including in notations that previously passed.

Deploy with a restart in the same command (17.8, Claude edition)

A fresh release report previously also approved a restart or stop of a service on the remote machine if it appeared in the same command. Now the deploy stays approved, and for the intervention in the running state of the remote machine, Code Guardian asks. Read-only remote calls and local commands do not trigger the question. In a run without a human, this means one more stop.

What this means for you: These are corrections: the gates read notations they previously missed, and a deploy with a restart now comes with an additional question. Some commands that used to pass unnoticed are therefore now stopped or questioned.

What does the new token check examine? (Claude edition)

Since 17.8, at the first session start after the update, Code Guardian checks once per project whether Claude Code settings cost a lot of context: the thinking level, the compaction window, and the size of the instruction files. If it finds something, it shows the lines and asks you a question: adjust or leave as is.

• Something is changed only on your explicit yes, only the named spot, with a backup and a named way back.
• Instruction files are never modified.
• In runs without a human, no check is made; the question then comes in a later session.

What the check does not do is listed below under the limits. How it behaves in the Codex edition is described in the section for Codex users.

What this means for you: You decide. Without your yes, your configuration stays as it is.

What about the council and the control room?

Council decision log (17.9)

The council can now find an earlier decision again, even after a long session has been condensed. The companion skill llm-council:

• enters every complete verdict in a decision log per project (.code-guardian-evidence/council-entscheidbuch.md),
• reads it at the start of the next deliberation,
• lets entries drop out that are older than 24 hours,
• never shows the log to the independent outside view,
• does not enter deliberations that were aborted.

Control room (17.9, Claude edition)

The quota node shows the week when no 5-hour window is reported, instead of “no quota feed”. Without an active session, it is no longer cut off at the top, and its color follows the same calculation as the card next to it.

What changes on Windows and in the log?

• Terminal detection under Git Bash (17.9). Until now, every run there counted as “without a terminal” because the query of the parent processes fails. With a programmatic start, this meant the plan approval by a human was skipped. Now Code Guardian reads the parent processes by a second route; if it cannot read them, it assumes a terminal.
• Session orchestrator on Windows (17.9, Claude edition). It could never determine its own session and refused every assignment; the session start counted one free session too few there. Now the own session is determined via the Windows process list.
• Fail-open log with simultaneously starting sessions (17.9). If several sessions started almost at the same time, lines in the log could appear twice, or a leftover handover could be overwritten. Now a start collects only handovers from finished starts and overwrites none.
• Fail-open log documented (17.8). The README and the update guide now explain the log of cases in which a gate could not check because of a missing tool, including a note on where older lines go. On Windows, the session start reports specifically when a gate could not convert paths (Claude edition).

What other fixes and improvements are there?

• Commit secret gate stops less often wrongly during merges (17.8). A value that was already present in the same file in one of the two versions, for example after renaming the key name, now counts as known. A newly added value, a value from a different file, and every private key still stop the commit, as does any doubt.
• Refusal text of the delete gate corrected (17.8). The text named /var/tmp as a throwaway location, but the gate never treated it that way. Behavior does not change; the text no longer promises it.
• Design proof measures real pages more accurately (17.8). For pages that are only fully built in the browser, the state probe measures after loading and after transitions have ended. For text, the weakest drawn spot counts, so an unreadable part inside a link stands out.
• Design proof: labels and color schemes (17.8). For checkboxes and radio buttons, the visible, clickable label counts toward the target size. Pages with light and dark color schemes and an opaque background are measured instead of aborted. The number of findings can therefore change in either direction.
• Slop detector in monorepos (17.8). It reads the package lists between the file and the root and no longer reports a sub-package's own dependencies as an invented import; a damaged package list no longer aborts the run.
• Task folder and friction counter (17.8). A task folder with a date in its name no longer gets the date twice. The friction counter no longer counts a red test before the green run, or a search without hits, as friction; its numbers are therefore not comparable with older retrospectives.
• Offloading the task overview (17.8, new, on call only). The task overview can move the texts of completed and dormant items into detail files so that the list stays small.

What this means for you: Fewer unnecessary stops during merges, and the findings of the design proof may change. Do not compare friction counter numbers with older retrospectives.

Which limits remain open?

We name them rather than hide them:

• Standard input (17.8). A few rare notations involving standard input are not yet read by the delete and migration gates.
• Remote ssh commands (17.9). The delete gate does not yet read a login shell without its own command, nor shells in containers.
• Council decision log (17.9). Text that looks like a credential is not entered; a harmless value can be rejected as well.
• Token check (17.8). The suggested values are our default, not a measurement on your project. It does not check settings imposed by administration (Claude edition).
• Orchestrator on Windows (17.9, Claude edition). If a link in the chain is missing, the own session remains unknown, and the orchestrator assigns nothing.

What this means for you: For delete and migration commands in these notations, do not rely solely on a gate to catch them.

What changes for Codex users?

The council decision log, the extended reading of shell wrappers, the remote ssh commands, the delete gate for root, home, and /tmp directories, the migration gate with xargs, the fail-open log, and the terminal detection under Git Bash are in both editions. The same applies from 17.8 to the scripts behind redirections, the commit secret gate, the corrected refusal text, the design proof, and the tools.

Differences that can be documented from the texts:

• Wrapper nested too deep (17.9). If a shell wrapper is nested deeper than Code Guardian reads, the Codex edition stops the command instead of asking.
• Token check (17.8). The Codex edition checks the thinking level, the compaction limit, and the size of the instruction file, and names the lines. It changes nothing itself: you adjust the setting by hand or leave it. There too, the reference values are our default, and in runs without a human, no check is made.
• Not in the Codex text. The Codex text does not mention the session orchestrator on Windows (17.9), the control room fix (17.9), or the question for a deploy with a restart in the same command (17.8).
• Companion skills (17.8). The description of the Codex edition now names every bundled companion skill with one line.

What this means for you: Under Codex, the decision and the manual work in the token check stay with you, and a wrapper nested too deep leads to a stopped command.

Status of the comparison measurement: the most recent valid run from 8 October 2026 measures v17.7: on average 5.7 with versus 5.0 without Code Guardian, p = 0.13, result “undecidable”. There is no separate measurement for 17.8 and 17.9; in total, there were 9 valid comparisons at that point.

You can find more about the product on the product page.

Frequently asked questions about Code Guardian 17.8 and 17.9

Do I have to do anything after the update?

You become active if the token check finds something and asks (Claude edition; under Codex you adjust the named lines by hand), and wherever a command is stopped.

Does the token check change my settings on its own?

No, see above: only on your explicit yes, and not at all in the Codex edition.

Why is a command stopped that used to run?

Because the gates now read notations they previously missed, such as scripts behind redirections or commands in additional shell wrappers.

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 change overviews (“What's new”) of versions 17.8 and 17.9, Claude and Codex editions (customer portal)

As of: 12 October 2026