Skip to content

Code Guardian 17.7: What Changes for You

Provimedia Redaktion 14 min read 08 October 2026 2 views
Vibe Coding, Code-Optimierung & Quality Gates
Code Guardian 17.7: What Changes for You
Illustrative image · AI-generated

If you deploy via ssh with options, environment variables or in a subshell, Code Guardian stops you from 17.6 onward. This is the change you will notice first. In addition, from the second prompt of a session Code Guardian injects roughly 80% less of its own text, and the new skill leitstand shows all Claude Code sessions on your machine at a glance.

This overview covers 17.4 (in the customer portal since 04.10.2026), 17.6 (since 07.10.2026) and 17.7 (since 08.10.2026). A version 17.5 was not released.

What you should do now:

  • Have you deployed via ssh with options, environment variables, a prefixed helper program, in a subshell or in a block of text passed to ssh? Then the deployment guard stops you from 17.6 onward. Write the approval report and run the command again, as with any other deployment.
  • Are there still files in your hook folder from the twelve guards that 17.6 removed from the package? The update names them. You do not need to do anything, and they can be deleted safely.
  • Have you set CG_STOP_AUFSCHUB in the Claude output? It no longer has any effect from 17.6.
  • Did you rely on the former total-lines limit of 900? It no longer applies as a default. If you want to keep it, set it explicitly via a switch or in the project file.
  • Do you update in an unattended run (claude -p)? The delete guard can stop the installer there. Start it in the terminal: bash install.sh. Under Codex the installer is called install-codex.sh.
  • Do you work on Windows, cloned Code Guardian via Git and set core.autocrlf=true there? Then clone again once and install from the fresh clone. Back up your own changes first. If you use the ZIP from the customer portal, you are not affected.
  • Do you also want to see your quota in the Leitstand? Then connect your own status line. The line for it is in the skill.

What is the Leitstand?

The Leitstand (German for control room) is new since 17.6. It is a small service that is reachable only on your machine. In the browser it shows all Claude Code sessions on this machine at a glance:

  • which session is working and which is waiting for you,
  • which one is stuck on a tool,
  • which one has an open decision, including the question and the possible answers,
  • usage over the last hour per project,
  • an analysis of where the tokens go: per session and subagent type, per project and model, over 24 hours as well as 7, 30 and 365 days.

If you connect your status line, you also see the 5-hour and the weekly limit with a projection up to the reset. The Leitstand is opened with /leitstand or with python3 ~/.claude/skills/leitstand/tools/leitstand.py oeffnen, on Windows with py. Access is protected by a key that the agent never outputs.

The Leitstand only reads. It does not end, write to or change any session, and it does not use any tokens. On macOS it starts automatically only if you explicitly switch that on.

What the display can show incorrectly:

  • After an account switch, the quota still shows the previous account until Claude Code writes the next status line.
  • An ended session can appear to be alive if the system has meanwhile reassigned its process number.
  • The Leitstand recognizes follow-up questions by the last line of a reply. A question in the middle of the text appears as finished, while a closing code block with a question mark appears as a follow-up question.
  • An open dialog in the session is shown as “waiting”, not as an alarm.

The Leitstand exists only for Claude Code, not in the Codex package.

What this means for you: If you have several sessions open in parallel, you can see in one place where something is waiting for you. The display is a guide, not a replacement for looking into the session.

How much less text does Code Guardian inject now?

Since 17.6, the longer notes that Code Guardian shows alongside a prompt appear in full only the first time in a session. After that, a single-line reminder follows. The rules stay the same. The notes in question are:

  • the signpost to the appropriate mode,
  • the task list,
  • the notes on interfaces, data analyses and root-cause analysis,
  • the offers for setup.

If the content of a note changes, for example the number of open tasks, it appears in full again. After a compaction, everything appears in full once.

Measured: from the second prompt of a session, Code Guardian injects roughly 80% less of its own text, namely 383 instead of 2,048 characters per follow-up prompt in the default setting. Depending on how you work, that is roughly 1 to 10% of a session's total tokens. The 80% refers to the text that Code Guardian itself injects, not to your entire session. The Codex package remains unchanged on this point.

What this means for you: The notes stay; they just no longer repeat at full length. How much this amounts to in your day-to-day work depends on how you work.

What security fixes do 17.4, 17.6 and 17.7 contain?

These are fixes, not new capabilities. They close spellings in which a command previously slipped past the guards. The four core guards check deletion, database migration, deployment and secrets in a commit.

In 17.7

  • Hidden follow-up command in strings. Certain spellings with special characters in strings could hide a subsequent command from the guards. These spellings are now detected, in the core guards, including deletion, database migration and deployment. If such a string is not closed, Code Guardian asks. You do not need to do anything.

In 17.6

  • Python no longer loads modules from the project directory. If a guard starts a short Python program, a file in the project could previously take the place of a bundled module.
  • Prefixed variables no longer hide a command. If a variable assignment stood in front of a command, the four core guards could overlook the command in certain spellings. Now they additionally check it without the assignment, and the stricter result applies.
  • Deployment via ssh in detour forms. Updating the server previously went through without an approval report if options, environment variables or a prefixed helper program were passed with the command, or if it stood in a subshell or a passed block of text. The guard now treats these forms like the simple one and requires the report. Read-only git commands over ssh (status, log, help) and a block of text that is only written to a file or printed remain free.
  • A restart on the server asks first. If a command over ssh restarts a service on a remote machine, stops it or pulls up containers there again, Code Guardian now asks. Nothing is refused in the process. A fresh approval report for a deployment in the same command also approves the restart. A mere reload of the configuration and the same commands on your own machine remain free. Under Codex this prompt is not active.
  • Keys in a freshly created repository. Previously, the commit check skipped a folder without a Git repository, even if the same command first creates the repository with git init or git clone and commits straight away. A .env file or a key file copied in there could thus end up in the first commit without any prompt. Now Code Guardian checks such a folder as if it were already an empty repository, and refuses a key. This also applies to a new repository in a subfolder of an existing project that is hidden by that project's .gitignore.

In 17.4

  • Write protection of the configuration on Windows. It now recognizes all path spellings. Previously, an unattended run could change the Claude Code settings on Windows in a certain spelling without being stopped. The gap already existed in 17.3.
  • Deletion. The delete guard now also reads a started shell script when the start stands behind a shell keyword, for example in a condition or loop. It also determines the location of a script correctly after a directory change that can fail or run only conditionally. A loop that first starts a script and then overwrites it in its body is refused.
  • Deployment. The deployment guard recognizes remote targets with spaces, options after the remote target, further prefixed helper programs and, on Windows, a drive as the source. It recognizes a secrets file in these spellings as well.
  • Migration. The migration guard now requires a gate report even without a schema command. This concerns:
    • interventions via helper functions of the database (ending sessions, setting sequences),
    • creating a table from a query,
    • copies into the database or into a file or program,
    • the shell and program exits of the clients,
    • overwriting inserts and upserts.
    The guard reads only commands that call a database client. The same words in a test filter or a message trigger nothing. Calling a stored procedure prompts a question, because its effect cannot be read from the command, as does writing a query into a new file on the database server. In the unattended run (claude -p) this prompt acts like a block.

What this means for you: Individual commands that previously went through unnoticed are now stopped or prompt a question. We do not claim that this covers every spelling. The fixes concern known forms.

Which false alarms and unclear refusals are gone?

  • Fitting recommendation in the unattended run (17.4). If an unattended run or the autopilot started a script that the delete guard cannot read, such as the installer during an update, the refusal recommended an exemption comment that has no effect there. Now it names the way that works: start the script in the terminal, for the update bash install.sh.
  • Correct description for ssh … bash -s < file (17.4). The refusal claimed “is in no file”. It now describes the case correctly.
  • The deployment guard names the name (17.4). If it recognizes a script only by its name, it gives that as the reason.
  • Refusals name the spot (17.6). If the migration guard refuses a command because of a started script, the refusal now always names the script and the lines that tipped the balance. This also applies to spots far back in the script and to spots that arise only from several lines.
  • Deliberately milder (17.4). A command that starts a script in the condition of while or until (or after !, do, then, else, elif) and then writes it in the same command was refused, even though the script cannot have been changed at the time of the start. This narrow form is now free. The opposite direction is stricter, see the fixes above.
  • No crash in the secrets guard (17.4). With an unclearly quoted word in a git call, it no longer crashes but asks. A git setting whose content is only determined at runtime also prompts a question.
  • Fewer false corrections in the analysis (17.4). The analysis of a session's friction no longer counts messages from the environment (replies from subagents, other sessions, system messages) as a correction by you.

What this means for you: Where a refusal previously led you astray, it now names the spot or the way that works.

What changes for guards, session start and Windows?

Twelve guards are removed from the package (17.6)

These are the guards that, since the guard core in 17.3, were no longer registered and therefore no longer checked anything. This changes nothing about behavior, because they were already switched off in 17.3. The number of hooks in the package drops from 27 to 15. This is not a new weakening compared with 17.3. Removed are:

  • the checks of glob patterns and of package installations before a command,
  • the scope fence (check and setting),
  • the check for access keys in addresses,
  • the characterization check,
  • six checks at the end of a reply (cold review, unsubstantiated findings, task list, retrospective, evidence and assignment).

An update removes their entries from the configuration, but does not delete older files of these guards by itself. The update names such leftover files.

Session start

  • Complete even without jq (17.6). On machines without the helper program jq, the session start previously stayed silent. Your agent received no working instructions at the beginning of the session, and this went unnoticed. Now Python takes over this job. The greeting under “New in” shows only the current version.
  • Further changes (17.4). If a session start aborts, the next session reports it exactly once. If a project stands on the installation itself, the session start no longer compares every file with itself there. After a compaction, the prompt note shows the full intake again instead of just a short line.
  • Reporting tool (17.4). It warns if a deploy or migration report is not ignored by git, and names the matching line for the .gitignore.

Windows

  • Task overview (17.7). A URL in the task list no longer makes the task overview hang or abort. With a foreign character encoding and with a locked folder for the next task number, it names the reason instead of a Python error. The session start no longer shows false zeros with a foreign encoding.
  • Further changes (17.4). A jq installed via winget now counts as present. A Git clone creates all files with uniform line endings, see the list above.

File size limit (17.6)

It now counts lines of code, including embedded code in strings and heredocs. Comments, docstrings and blank lines no longer count. The former total-lines limit of 900 no longer applies as a default. If you set it explicitly (switch or project file), you keep it as a voluntarily stricter limit.

What this means for you: Nothing changes about the behavior of the removed guards. If you still have them lying in the hook folder, clean up.

What changes for the review agents, data analysis and multiple sessions?

Review agents with a deadline (17.6)

All 14 review agents now keep to a deadline: 40 minutes or 120 tool calls, whichever is reached first. Agents without a shell count only the tool calls, and an assignment can set the deadline differently. When the deadline is reached, they deliver a partial result with a list of what was not checked, instead of continuing without output. A review agent that is aborted has left an interim state since 17.4.

The diff reviewer and the layer reviewers additionally write their findings as a separate section in their evidence file, so that they arrive verbatim in the report. The diff reviewer treats every statement of the diff as unsubstantiated until it has checked it.

If a subagent aborts at a usage limit, Code Guardian instructs your agent to notify you immediately and to continue after the reset, instead of silently restarting or switching the model.

What this means for you: A review agent no longer keeps running without output, and you see what it did not check.

Data analysis, council and mail (17.6)

  • In a data analysis, every filter is first checked against a known hit before its result counts. A zero from an unchecked filter counts as unsubstantiated.
  • In the council, which letter belongs to which advisor is recorded before the mutual review.
  • Under autopilot, no mail currently goes out. It is prepared, recorded in full wording, reported in the final report under “Awaiting approval” and waits for you.

Working with multiple sessions (17.6)

The role of an orchestrator session is preserved across a compaction. After /compact it receives a short note on how to continue. Worktrees are preferably entered via the tool for switching into a worktree. If a step is waiting for another session, it appears in the orchestrator's plan and goes out as a new assignment as soon as the precondition is met.

Tools (17.4)

The detection of Vitest finds configurations with .mts and .cts as well as projects without a configuration file. An empty project or a test file without a test stays red.

Which limits remain open?

We name them rather than keep quiet about them:

  • Scripts on the server. What is recognized is what stands in the command line itself. A procedure that is stored in a script file on the server and called there is not visible from here.
  • User switch on the server. It is not yet read in every form. We are working on this.
  • Command wrappers. They are not yet evaluated completely.
  • Prefixed variables in scripts. Within called scripts, this detection does not yet apply. That follows in a later update.
  • Very large folders without a repository. If a command creates a repository in the home or root directory, for example, the check can take up to its time limit and then asks. In this case it never approves silently. Because it cannot be determined in advance in which folder the repository will be created, Code Guardian checks every folder in question. If one of them contains a key file that would not be committed at all, an unnecessary refusal can occur. The stricter direction is chosen deliberately.
  • Fresh repository in a shell wrapper. If the command stands in a further shell wrapper, the new check for keys in freshly created repositories does not yet apply. Work on this continues.
  • Windows without a terminal. With programmatic entry points (SDK, MCP server, GitHub Action), Code Guardian on Windows does not detect whether a human is sitting at the terminal after all. Then the plan approval by the human is omitted. The blocking guards, the write protection and the audit remain active. We will fix this in one of the next updates.
  • Abort at session start on Windows. If only the outer launcher of a session start aborts, the abort goes unreported.
  • Migration guard. Additive writing (INSERT, LOAD DATA) is free. The guard does not distinguish between a local and a production database, apart from the test databases of Code Guardian. An INSERT can have external effects via triggers or queues.
  • Deletion means files and directories, not records that a program deletes. Not every remote execution that changes running state is detected.

In addition, version 17.3 had announced four items for 17.4 that were not yet contained in the Claude output of 17.4 and remained planned:

  • The files of the deregistered guards were still in the package in 17.4. Version 17.6 removed them.
  • In some command forms, the migration guard does not yet assign a migration or its approval report to the right project root in every case.
  • The deployment guard does not yet recognize a transfer script in every case.
  • design-beweis may measure pages that build their content only after loading too early, and does not evaluate contrast with a switchable color scheme.

For the last three items, the release texts of 17.6 and 17.7 give no new status.

What this means for you: Do not rely solely on a guard triggering for deployments, migrations and delete commands. For scripts and unusual command forms, check yourself whether it took effect.

What changes for Codex users?

The security fixes, the deadline of the review agents, the changes to the refusal texts and the data analysis correspond in essence to the Claude output. The following is different:

  • The Leitstand is not in the Codex package.
  • The prompt on a restart over ssh is not active under Codex, because there every prompt would become a block.
  • Where the Claude output asks, Codex stops the command: with an unclosed string (17.7), with a stored procedure and with an unclearly quoted word in the secrets guard.
  • In the Codex package the installer is called install-codex.sh. The refusals recommend it for starting in the terminal.
  • The Windows security fix from 17.4 concerns the Codex settings there if the configuration directory and the target were spelled differently.
  • The Windows limit for plan approval concerns, under Codex, sessions with approvals switched off.
  • Instead of the four open items from 17.3, the Codex output names three: the assignment to the project root for the migration guard, the transfer script for the deployment guard and, with your own CODEX_HOME, repair hints pointing to ~/.codex as well as the missing incident analysis at the end of the session.
  • The Codex text mentions neither the session start without jq nor the changes for multiple sessions.

What this means for you: Under Codex, a prompt from the Claude output usually becomes a stopped command. The prompt on a restart over ssh does not apply there at all; such commands run under Codex without a prompt. Start scripts like the installer in the terminal.

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

17.7 went through the test battery before release. The table shows the figures compared with 17.3.

VersionLayerspassedfailedskipped
v17.315314805
v17.716015505

For context: eight layers were added and one was dropped. The layers that check both error directions of the guards ran without a failure: the cases checked were rightly stopped or rightly let through.

The package figures of 17.7 were recounted on the zip: 5 modes, 7 gates, 15 hooks, 22 detectors, 27 skills and 14 review agents. In 17.3 there were 27 hooks and 26 skills. The lower hook count is explained by the twelve removed guards; the additional skill is the Leitstand.

There is no new comparison measurement for 17.7. The last valid one is for v17.2 from 28.09.2026, and none has been added since the article on 17.3. We therefore give no figure and invent none.

Conclusion: The test battery ran without a failure, and five layers were skipped, as many as for 17.3. Whether Code Guardian improves the work result is shown only by the comparison measurement, and that is not available for 17.7. You can find more about the product on the product page. You can read the predecessor article at Code Guardian 17.3: What Changes for You.

Frequently asked questions about Code Guardian 17.7

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

Not for basic operation. The fixes to the guards take effect by themselves after the update. You only need to act in the cases listed above.

Does the Leitstand cost me tokens?

No. It only reads and uses no tokens. It does not end, write to or change any session.

Is less checked now?

At its core no, but deliberately milder in two places. Since 17.4 the delete guard lets one narrow form through, in which a script starts in the condition of while or until and is then written to in the same command. And since 17.6 the total-lines limit of 900 no longer applies as a default.

The twelve removed guards had not checked anything since 17.3. Deletion, database migration, deployment and secrets in a commit are still blocked, and since 17.4, 17.6 and 17.7 they see more spellings than before. The open limits are listed above.

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 to keep Code Guardian up to date afterwards is explained at provimedia.de/code-guardian/updates.

Sources

  • Published update guides for versions 17.4, 17.6 and 17.7, Claude and Codex output (customer portal)
  • Test evidence for versions 17.3 and 17.7 (customer portal)

As of: 08.10.2026

Share this article

Stay up to date

Get the latest articles, insights and industry updates straight to your inbox.

Unsubscribe at any time. See our privacy policy.

Decide for yourself what Google shows you

Google lets you choose which sources appear more prominently in your search results: in Top Stories and in AI answers. Two clicks, and you see the sites you trust.

Add provimedia.de to my preferred sources

Checks You Can't Skip

The skill package for Claude Code and OpenAI Codex: seven gates stand before every deploy, migration, new dependency, data-based claim, finding, decision question and legal text. One company license, unlimited developers across your organization.