v5.7.0

[5.7.0] — 2026-08-21

The guard is now something you can see, tune and audit, instead of a set of rules that only spoke up to
refuse something.

Added

• A Guard view in the chat's view row. Every alert raised in this project: what matched, what the rule
  saw, the verdict, and what let the call through if anything did. Free-text search, multi-select filters by
  category and by rule, and a Whitelist button on any entry. Retention is configurable; capped at 500.
• The guard keeps its alerts in the IDE's password safe, per project — which is what makes the view
  above possible, and what puts the guard's rows back when you reopen a chat. Each row returns anchored to
  the call it judged, and an alert raised inside an agent is drawn in that agent's transcript, not the main
  one. An Allow All given on a card comes back without its undo link: that approval died with the IDE.
• A shield in the chat's button row, left of auto-scroll: switches the guard to Allow All for a chosen
  duration, and back with one click. Unlit whenever the guard is not deciding.
• Settings ▸ Claude Code Security, its own page: the guard's mode, a mode per rule with All Enforcing /
  All Permissive per category, live suspensions you can end, extra credential globs, extra blocked domains,
  and the whitelist at three reaches — all rules, one category, one rule. Any rule can be whitelisted;
  credential and foreign-path rules ask for confirmation first.
• A warning row whenever a rule matched and the call ran anyway. It names the rule, what it saw and what
  let it through, and carries the link that undoes it — including Remove from whitelist, which takes the
  command off whichever of the three lists is letting it through, narrowest first.
• A Whitelist Command link on a guard block, beside Disable rule. Files the exact command under the
  rule that refused it, and will not add a duplicate.
• A Vulnerabilities view. Checks your project's dependencies against a public advisory database
  (OSV.dev) for known CVEs, filters by severity, and hands the findings to Claude to plan how to solve
  them — reading your code and checking current advisories first, not just bumping a version.
• Export, import and migrate settings, including straight from another JetBrains IDE on this machine. An
  exported file never carries your environment variables; a keychain-to-keychain migration does, because it
  never leaves the machine. A permission mode that would weaken security is refused on the way in.

Changed

• Both settings pages rebuilt, and they now fit the window. Titled groups instead of one column of forty
  rows, with Tools, MCP and Advanced folded away; every note sits under its own field and re-wraps as you
  resize. Nothing runs off the right edge any more.
• The guard has a mode: Enforcing, Permissive or Allow All. Enforcing refuses, Permissive asks on a card
  every time, Allow All lets the call run. Rules take the first two and are Enforcing by default.
• Settings are per project, per IDE installation. Two repositories can disagree about the model, the
  permission mode or a security rule. The login stays global, and signing out no longer wipes your settings.
• Always allow this command on a guard alert is per chat, and in memory. It was written to the settings
  document, so one conversation answered for every other one, for ever. Revocable from that chat's ⚙ menu.
• Every view redraws in place instead of from scratch, so a filter, a scroll position or an open card
  survives the transcript refreshing underneath it, and an agent's transcript no longer flickers as it runs.
• The branch graph draws to the full height of its row. An <svg> is a replaced element, so a tall row —
  uncommitted changes with its file list, a commit carrying several ref tags — had its edge stop short of
  the next commit and its dot sat below the junction.

Security

• Privilege escalation is refused: sudo, su, doas, pkexec, runuser, setpriv, run0, the
  desktop wrappers, osascript asking for administrator privileges, runas,
  Start-Process -Verb RunAs, psexec, wsl -u root. Matched only where the payload executes, so a
  file that documents sudo apt update trips nothing. Whitelistable per command.
• The "outside the project" rule now sees paths inside shell commands. It only ever read a tool's own
  location argument, so Read /home/you/notes.txt was refused while cat ~/notes.txt was not — and the
  shell is where the work happens.
• Obfuscated payloads are decoded before they are judged — hex and reversed strings.
• Destructive orchestration covers OpenShift: oc delete project alongside the kubectl equivalents.
• Recovery inhibition covers VSS and APFS snapshots.
• A variable that decides which code runs is never an innocent declaration. PATH, LD_PRELOAD,
  BASH_ENV, GIT_SSH_COMMAND and their family are checked wherever they are set. Declaring a path is not
  reaching it; expanding it is.
• System binaries and inert devices are not reaches: /usr/bin/git status and 2>/dev/null still run.

---

Verifying this release. Both the .asc files and the tag are signed by the project's CI
signing key, and everything needed to check it is in the one file attached here as
trust-chain.asc: that key's public half, plus the two hardware CAs that certify it — so the
chain terminates in keys whose private halves have never been on a computer.

One file rather than three because a chain is imported whole or not at all. A certification you
have no way to follow is indistinguishable from one nobody made, which is exactly the assurance
the two CA keys carry.

What the signatures do NOT assert is that a human pressed a button: the release is cut
automatically from the merge into main, with no approval step and no required reviewer. What
stands behind it instead is mechanical, and it is worth being exact about — main accepts nothing
but pull requests that are up to date and have all nine required checks green (among them the JVM
and frontend tests, both CodeQL scans, the dependency audit and the plugin verifier), that
protection can be bypassed by nobody including admins, and this workflow refuses to publish a
commit that is not reachable from main or a version number that has already been released.

gpg --import trust-chain.asc
# The CI key is the LAST block in that file — the CAs come first, and the awk below takes the
# last one deliberately. Then: endorsed by both of them, not merely asserted by a file.
gpg --check-sigs "$(gpg --show-keys --with-colons trust-chain.asc \
                    | awk -F: '$1=="pub"{getline; if ($1=="fpr") f=$10} END{print f}')"
gpg --verify claude-code-native-*.zip.asc   # these bytes came from this workflow
git verify-tag <tag>                        # this workflow cut this release from main

The one check worth doing that this file cannot do for you. Everything above arrives from
this repository, so it proves the release is internally consistent and nothing more — whoever
could publish a forged artifact could publish a bundle agreeing with it. The CAs are therefore
also on keys.openpgp.org, an operator with no relation to GitHub, and fetching one by
fingerprint is what turns the chain into evidence:

gpg --keyserver hkps://keys.openpgp.org --recv-keys <CA fingerprint from SECURITY.md>

Two copies of the same CA from two unrelated publishers either agree, or the disagreement is
the story.