Code Guardian 17.13: Done Means Proven

The agent reports “tests green,” yet the test run never happened. As of Code Guardian 17.13, such a task no longer closes. This overview of versions 17.10 to 17.13 answers one question: how can you tell that the result is correct?

You can find the article on the previous version here: Code Guardian 17.9: What's New.

What you should do now

1. Codex users with custom profile values only: note down your values from agents/cg-*.toml. An update resets them.
2. Install the update with bash install.sh. The new notices take effect immediately.
3. Codex users: enter your values again afterwards.
4. Create your next task with aufgabe.py neu; aufgabe.py is the tool for task folders. The new folder automatically carries “Graph: ja”.

When does Code Guardian consider a task done?

Since 17.13, every new task folder carries a work graph with six nodes. You prove these six; Code Guardian records the closing itself.

Every node is open, claimed, proven or not applicable. “Claimed” means: entered as done, but without a verified proof. That does not close anything, because a line written by hand proves nothing.

A node counts as proven only with evidence: a log file with exit=0, a commit or a justified “not applicable.” The log and the commit must be newer than the graph start, that is, the point in time when the folder received its graph.

On closing, Code Guardian checks all nodes again. If a proof is missing, it reports “NICHT FERTIG: N Graph-Knoten ohne Beleg.” A claim alone does not close a task.

What this means for you: “Done” is verifiable. A third party can see in the folder what was checked and with what.

How to prove a node

1. Look at the status, read-only: aufgabe.py graph --id <id>.
2. Choose one proof per node, with aufgabe.py beleg --id <id> --knoten <knoten> and exactly one of these options:
   • --datei <protokoll>: The last non-empty line must carry exit=0, and the file must be newer than the graph start.
   • --sha <sha>: The commit must be newer than the graph start and lie in a branch or tag.
   • --entfaellt <grund>: Without a reason, the node stays open.
   • Special case pre-check: there, --rot <protokoll> proves the red run before the change, whose exit code is not 0.
3. Close with aufgabe.py abschliessen.

After a git commit, the hook proves the edit node itself if the commit is at most ten minutes old. It never proves the test run (suite).

If NICHT FERTIG appears: aufgabe.py abschliessen names the matching call of aufgabe.py beleg for each missing node. Run it and close again. Note: abschliessen reads only the section ## Erkenntnisse. Findings under a heading of your own do not count.

Will this block my ongoing work?

No. The block applies only to new folders with “Graph: ja”. Existing folders get the graph and just a notice.

Three notices are new: [graph], [wiederaufnahme] and [abbruch]. The last one reports an aborted review subagent, which previously vanished silently. None of these notices blocks anything.

In addition, the false alarm of the fence, the file boundary of a task, in nested repositories is fixed.

What this means for you: The proof requirement affects only tasks you newly create. Everything else keeps running as before.

How can I tell where a finding comes from?

The review now knows risk level H. It applies when a change touches the blocklist, that is, areas such as database, payment, deploy and secrets. It also applies when the scan for security-relevant code patterns reports a value above 0.

The reviewer arms, the independent review agents, then run with a higher thinking depth (xhigh). In the closing block, the “Risiko H” light turns on. After three cold-review rounds a round cap kicks in, so the review does not go around in circles forever.

Every finding comes with a classification of the error type, including a search pattern for places where the same error may still lurk. The origin is added as well: own, pre-existing or undetermined. The origin does not shift any verdict. It only shows whether the finding comes from your change.

Before changes to an existing architecture, Code Guardian also requires a profile sheet with seven fields.

What this means for you: Risky changes are checked more thoroughly, and you see right away whether a finding is your own.

Are my numbers correct when I work with working copies?

Yes, that is the goal of these changes: your findings and numbers refer to your code and no longer to copies of it. Anyone working with Git working copies under .claude/worktrees/ previously got distorted numbers.

Since 17.12, working copies are no longer counted twice. Seven tools were switched over, plus Windows fixes for clone search and dependency checking.

17.13 follows up: further check tools, including the scar search, the plan inventory and the analyses for PHP, Python, JS and HTML, skip working copies and the PHPStan cache. The tools also no longer inherit GIT_DIR and GIT_WORK_TREE.

Exception: secret scanning and legal-text detection deliberately keep checking working copies.

What this means for you: If you work under .claude/worktrees/, you do not need to do anything. The switched-over tools skip the copies on their own.

Can Code Guardian learn on its own?

Since 17.11, there is the skill auto-self-improve. It looks back on its own after the work is done. It is off by default, logs before every change and touches no safety latch. Since 17.12, it waits as long as a question to you is open.

To switch it on: in ~/.claude/code-guardian.conf, set the line auto_self_improve = true. The default is false.

Also since 17.11: the skill autorun for unattended working through tasks and a loop notice that makes a step that fails again and again visible. Neither of them triggers a safety latch, and the notice blocks nothing.

What this means for you: You decide whether the retrospective runs by itself. Without your setting, everything stays as it was.

Why does a latch stop me, and why less often?

Latches are the protective locks in front of risky commands. A stop should have a reason; a harmless command should not trigger one.

Since 17.10, the migration and deploy latches recognize a remote call even when ssh does not appear literally in the command but comes from a variable. Previously, a migration or deploy on a remote machine then ran through without a stop. The delete latch recognizes remote deletion via an ssh variable, also behind timeout.

At the same time, there are fewer false alarms:

• A read-only grep on a deploy script is allowed (17.11).
• A deploy name inside a literal no longer counts as a deploy (17.11).
• A fully quoted ssh payload that only deletes a throwaway file you created yourself no longer triggers (17.10).

The refusal texts of the delete latch are clearer. The latch now asks when a number in the command cannot be read unambiguously (such as nan or inf), instead of guessing.

What this means for you: Fewer stops on harmless commands, more attention to real risks.

Which limits remain open?

We call them open:

• Proof requirement: It applies only to new folders with “Graph: ja”. What you can do: create important tasks anew, then the requirement applies.
• ssh variable: It is recognized by how it is written, and not every spelling is covered. What you can do: for risky commands, write ssh literally in the command instead of calling it through a variable.
• Approval report: The migration and deploy latches still accept a self-written report. The gap is planned for an upcoming release. What you can do: read approval reports critically yourself.
• Windows: A run that ended normally no longer counts as aborted. The known limit: a run that aborts exclusively at the Windows launcher under Git bash is no longer recognized as an abort after the fix. What you can do: with such an abort, check the output yourself.
• Codex: Under Codex, risk level H is only reported and raises nothing. What you can do: set the thinking depth in the profile yourself.

What this means for you: Do not rely on an approval report alone for migration and deploy.

What changes for Codex users?

The Codex output gets the work graph with proof requirement and the origin details. Three differences come on top:

• Risk level H is only reported, it raises nothing. You set the thinking depth of the reviewer arms in the profile yourself.
• An update overwrites the agent profiles agents/cg-*.toml and resets custom values. Steps 1 and 3 above are meant for this.
• Cost measurement previously showed a silent zero instead of the values with session-cost --geld. Now the token counts come from Codex's messages.

What this means for you: Note down your profile values before the update and enter them again afterwards.

What does Code Guardian deliver, measurably?

Status of the comparison measurement: the most recent valid run, from 15.10.2026, measures v17.10: on average 5.9 with versus 5.2 without Code Guardian. The value is a score per task; higher is better. The p-value is 0.017, and the result reads “proven.”

For 17.11 to 17.13 there is no measurement of its own yet. In total, there are 10 valid comparisons.

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

Frequently asked questions about Code Guardian 17.13

What do I do on NICHT FERTIG?

Run the call that aufgabe.py abschliessen names for each missing node. Then close again.

How do I switch on the self-retrospective?

In ~/.claude/code-guardian.conf, set the line auto_self_improve = true. It touches no safety latch and changes nothing irreversible.

What happens after three cold-review rounds?

The light shows “Rundendeckel 3 Runden — Ansatz überdenken.” Then rethink the approach instead of running a fourth round.

Do I need to watch anything as a Codex user?

Yes: steps 1 and 3 above and the thinking depth of the reviewer arms in the profile.

Note on 17.11

In the note on 17.11, two statements were imprecise: the three review agents were not new, and the profile sheet has seven fields.

Sources

• Changelog Code Guardian 17.10–17.13 (Claude package and Codex package), in the customer portal
• Manufacturer's comparison measurement, run of 15.10.2026

As of: 26.10.2026