Code Guardian 17.16: Done only with proof, and a guard gap

When is a task done? Since 17.15, new task folders only close once every mandatory criterion is backed by proof. The second reason to read this update: the guards for deleting, deploying and migrating have a gap, and 17.16 corrected the note about it. This overview of 17.14 to 17.16 explains when a task counts as done, what the guards now catch, which gap remains and what you should do beforehand.

The article on the previous version is available at Code Guardian 17.13: What's new.

What you should do now

1. Run the installer. During the update, it reports each locally changed or added file of a companion skill individually.
2. Make sure Python 3.9 or newer is installed. If python3 is missing, every code edit shows a [toolchain] line with the fix.
3. Create your next task with aufgabe.py neu. The new folder carries acceptance criteria.
4. Run test runs that are meant to serve as proof through beleg-lauf.py. That way the log is sealed.
5. Write commands for deleting, deploying and migrating without a redirecting block, or check them yourself. The forms are listed in the section "Which limits remain open?".

When does a task close now?

Since 17.15, new task folders (aufgabe.py neu) carry acceptance criteria. They are frozen and sealed before the first commit of their own. aufgabe.py abschliessen only closes once every mandatory criterion is backed by proof.

What this means for you: "Done" requires proof for every mandatory criterion. A claim is not enough.

How does a test log become proof?

The new tool beleg-lauf.py seals a test log with the content state of your working tree. If the tree changes during the run, the proof counts as stale. Skipped tests (SKIP) prove nothing. If HEAD has meanwhile moved to a different commit, for example after a rebase, the rejection names exactly that case.

On top of that come hidden acceptance cases. A criterion of the type review · holdout is only met by cases that a fresh subagent writes after the freeze and that are not visible during the build. Every case needs a sealed log.

What this means for you: Start the test run that is meant to serve as proof through beleg-lauf.py and change nothing in the working tree in the meantime. Do not count on skipped tests.

What can the two new skills do?

The Claude package now has 31 skills, up from 29. Both new ones start only when you call them and are on the blocklist of the write guard. In unattended runs they cannot be overwritten.

goalengine

• What it does: It turns a goal intention into a goal contract with fixed versions. A contract only takes effect after explicit approval of a named version and is frozen afterwards. A criterion counts as met only with proof: a commit, a log with exit=0, a URL or a named manual check. On approval, it outputs a copyable /goal prompt.
• What it does not do: No hook enforces the contract.
• Where you see it: The control panel (Leitstand) has the new tabs "Goal Engineering" and "Todos" for each project. Your goals live in the .goals/ folder of the respective project; ~/.claude/goals/ only holds the list of projects with goals.

codeguard-master

• What it does: It watches the projects on your machine that you name for it (without a list, those with goalengine goals). At a fixed interval it collects the situation without a model.
• What it does not do: It does not intervene on suspicion. Only when a fixed trigger fires anew does a model without tools pick a few measures, with a minimum interval and a daily budget. Outgoing texts come only from fixed templates. If it is wrong too often, it switches to reporting only.
• What it costs: You set up the interval via launchd yourself, and every model run costs tokens.

What this means for you: Both skills are offers. Without your call, nothing happens.

What changes in the check after every file change?

Since 17.14 it runs in a single python3 process, the module hooks/_cg_reminder.py. Before, it started around 115 helper processes. The texts and the order of the notices stay the same. You do not have to do anything: the check runs by itself after every edit and only needs python3 (see step 2 above).

Result on Windows: In the typical case (median), the check is 2.4 to 7.7 times faster than before. Only for Markdown files does it stay the same.

Goal and status: On Windows, the check should take hardly any longer than on Linux and macOS. Measured, that means: out of 100 calls, 95 take at most 1.25 times as long as the slower of the other two systems. For shell scripts and Markdown, this holds according to the preliminary measurement. The status of the other languages is given in the section "Which limits remain open?".

Further changes from 17.14 that you will notice:

• [security-shape] now flags security-relevant patterns only in the lines the edit wrote. The notice only runs for PHP, Python, JavaScript, TypeScript and Vue.
• The new notice [plan-abweichung] appears once per file and session when you edit a code file that is not in any open TRACE. It never blocks.
• log-inventur.py inventur finds the log sources and marks which file is AKTUELL (current) and which is VERALTET (outdated).

Will a guard stop me more often now?

Where something used to slip through, yes. Where it stopped you wrongly, less often.

Stricter since 17.15:

• The delete guard and the migration guard check a program that is piped into an interpreter the same way as a program after -c.
• An escape-hatch comment no longer releases anything if an executable line follows it.
• A deploy report now only applies to the targets of its Target: line.

The guards now newly detect:

• rsync, scp and sftp to an IPv6 address,
• a deploy script via stdin or with a leading shell switch,
• an interpreter with an .sql file.

Two consequences of this strictness, the SQL linter and env -S, are named in the list of open limits further below.

Fewer false alarms: Pure reading and configuration files no longer count as "written and started". Read commands of npm and composer no longer count as writers, and words such as "form" or "platform" no longer count as a delete command. A commit message with an escaped quotation mark also no longer triggers a false alarm.

New: If the same guard rejection or the same tool error occurs for the third time, Code Guardian names the intended way out once. The notice never blocks.

In addition, review agents with shell access no longer write into your working tree. Writing git probes now run only in a throwaway repository.

What this means for you: More rejections for the newly detected forms, fewer for pure reading. On the third identical stop, Code Guardian names the way out.

Which fixes are included?

These are fixes, not new capabilities:

• During the update, Python bytecode no longer counts as a locally changed file of a companion skill.
• aufgabe.py finds the task folder even from a git working copy (reported by a customer).
• The audit reminder no longer appears for files in the scratchpad or in $TMPDIR.
• The session start arrives in full again: anchor, todo count and drift notice are back in the context.
• The quota display in the Leitstand shows a fresh measurement even when Claude Code supplies only the weekly value.
• Code Guardian shows the notice about /clear after abschliessen only when the session no longer holds an open task.

Also new: With aufgabe.py uebergabe you write a handover file at the end of a session.

What changes for Codex users?

The Codex edition gets the acceptance criteria, beleg-lauf.py, the stricter guards and the check in one process. The skills goalengine and codeguard-master do not exist there. Further differences:

• A read-only PowerShell call with $env: or Select-String is no longer stopped as env -S.
• The writing git probes of the review agents are omitted and named in the report as not executed.
• The installer rejects a relative CODEX_HOME, also with --probe, and does so before the first write access. Set it to an absolute path, for example $HOME/.codex, or leave it empty.

Which limits remain open?

This list is the complete place for all caveats of this article.

• Commands in a block with a redirection behind it: The note on 17.15 mentioned only a rare notation of the migration guard here. That was too narrow, and 17.16 corrects the texts; the behavior of the guards has stayed the same. The delete, deploy and migration guards overlook commands in a block whose input is redirected only after the block. They do detect the same instruction without a block. These are the forms in question:

  { befehl; } < eingabe
  ( befehl ) < eingabe
  while read zeile; do befehl; done < eingabe
  if bedingung; then befehl; fi < eingabe

  This will be fixed in the follow-up release. Until then, write risky commands without a redirecting block or check deleting, deploying and migrating yourself inside such a block.
• SQL linter: Even a pure linter with an .sql file is stopped. The version does not name a way out.
• env -S: With additional words it leads to a prompt in the Claude package and to a block under Codex. Here too, the version names no way out.
• Windows runtime: For PHP, Python, JavaScript and CSS the goal has not yet been reached. The macOS baseline of the preliminary measurement was measured under load; a re-measurement on a quiet machine is planned for the next release. Acceptance of the goal is firmly scheduled for the next release and is not counted as done.
• Codex: Hidden acceptance cases (review · holdout) are not available there.

What this means for you: Acceptance has become provable, the guards are tighter. One gap remains until the follow-up release, and we name it.

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

Sources

• Code Guardian 17.14–17.16 changelog (Claude package and Codex package), in the customer portal

As of: 04.11.2026