ShieldCortex 5.7.0 was released on 11 October 2026. It is a minor release on 5.6.0. The supported Node range (^22.14.0 || >=24.0.0) and the Cloud pin are unchanged. Action Guard stays off by default in the shared ShieldCortex config, but what the guard does depends on the host: the Hermes plugin, once enabled, has its own enforcement setting. The Action Guard section below sets out each host.

Two changes affect what leaves your machine or reaches an agent's prompt, so they come first. The changelog has the short list.

Bulk quarantine sync uses the same gate as automatic sync

The local dashboard has a button that syncs the quarantine to Cloud (POST /api/quarantine/sync-to-cloud). Until 5.7.0 it built its own payload and sent each stored row's original content as-is: no sensitive-level exclusion, no project filter, no metadata-only mode and no redaction.

In 5.7.0 the button and the automatic sync share one payload builder. It applies the sync controls first (by default, excludeSensitive keeps out rows classified CONFIDENTIAL or above, and rows in the new PERSONAL tier described below), then the write-time PII redactor, then credential redaction, before anything leaves the device or is queued for retry. Opting in to sensitive sync is not an opt-out from PII redaction; SHIELDCORTEX_PII_REDACTION=off still turns PII redaction off.

A stored row is also no longer graded from its raw text alone. The route rebuilds the level the live pipeline gave it from the linked audit entry where there is one, and otherwise takes the strictest of several views of the row, including the exact pairing the live pipeline uses (sanitised content beside the original title). An obfuscated or already-redacted row that the automatic sync would have excluded is not shipped by the bulk button. The response gains an additive skipped count beside synced and total.

What this does not mean: rows that pass the filters are still sent to Cloud, redacted, unless you use metadata-only mode. Redaction replaces recognised kinds, such as national insurance numbers, SSNs, tax ids and salaries with the contact details beside them, and recognised credentials. It is not a guarantee that every personal detail or secret is caught.

Prompt-time recall is scoped by lane

On a single-workspace host, the owner's chat, cron jobs and liveness probes share one project, so every probe could draw on the owner's full memory pool. In 5.7.0 the Claude Code UserPromptSubmit hook picks a lane for each turn, from the markers OpenClaw's prompt builders write or from a valid SHIELDCORTEX_RECALL_LANE pin (interactive, cron, subagent or automation; any other value is treated as automation).

Cron and subagent turns recall only error, pattern and decision memories, and only rows labelled PUBLIC. Unlabelled rows count as INTERNAL.
Liveness and other automation turns recall nothing by default. recallLanes.automation.recall opts them in, to PUBLIC rows only.
Your own unmarked chat stays interactive and recalls what it did before.

This changes by default, with no opt-in. recallLanes in ~/.shieldcortex/config.json changes the categories; the PUBLIC-only rule for non-interactive lanes is not configurable.

The limits matter. Lanes scope only prompt-time recall in the UserPromptSubmit hook, and only for turns it detects from a marker or reads from a valid pin. The stored label decides what is withheld, so a private note the classifier missed and labelled PUBLIC can still reach a non-interactive lane. SessionStart context, MCP tool reads and dashboard previews are not lane-scoped.

A PERSONAL tier for private-life notes

The writer-side classifier gains PERSONAL, between INTERNAL and CONFIDENTIAL. Your interactive recall still sees it, and the default excludeSensitive keeps it out of Cloud sync. Existing rows keep their labels until you backfill:

shieldcortex memories reclassify (optionally with --project) is a dry run by default.
Add --execute to apply it. It only ever raises a label, never lowers one.

If you consume shieldcortex/defence: the exported SensitivityLevel type gains 'PERSONAL', so code that switches exhaustively on the level, or keeps a Record<SensitivityLevel, …> map, needs a PERSONAL case.

OpenClaw setup says why it failed

On an npm install, shieldcortex setup openclaw printed only the last native plugin install refusal, from a linked-folder attempt against a plugin folder the npm package never ships. That hid why the supported realtime package install failed. In 5.7.0 every attempt's refusal is printed, package install first, and the linked attempt runs only when the local plugin source exists. A missing OpenClaw config is reported as a config problem, naming the config path, and a present config is never called missing. npm run build hints appear only in a source checkout; packaged installs are pointed at shieldcortex openclaw install or the realtime package instead.

Action Guard changes, and their limits

Action Guard is off by default in the shared ShieldCortex config. Setup offers three choices: Off, Watch only, or Enforce when ready. Turning the guard on does not mean it asks about or blocks every dangerous call. Watch only and Enforce when ready apply to the Claude Code hook and the OpenClaw plugin. Under Enforce when ready, their ordinary dangerous tier stays watch-only, recorded rather than held, until reviewed effectiveness evidence ships, and none has shipped yet. Setup does not offer plain enforcement, but an install that explicitly configures it is a separate posture: it does not wait for the readiness gate. The Hermes plugin is different. Once enabled, it has its own enforcement setting, which enforces by default, ignores the readiness gate, and drops to advisory only on an explicit opt-out. Hermes has no approval prompt and, when enforcing, blocks held calls instead; even in advisory mode it still blocks hard-block verdicts and calls recognized as attempts to change the guard's own state or config. On Claude Code and OpenClaw, once the guard is on, the existing exceptions are still held or blocked whether it is watching or enforcing, and a held call can show an approval only where an approval surface is available. Memory writes are scanned; tool results are not scanned automatically. Nothing in this release is a claim about how effective the guard is.

Readiness evidence survives a release. Enforce when ready used to match readiness evidence on the full adapter version plus policy hash, so every release reset it. It is now keyed on the adapter and the policy hash, so a release that keeps the policy hash keeps its evidence. When the hash changes, the prior policy's evidence is carried at a discount set by actionGuard.readiness.priorPolicyCarry (shield config only, 0 to 1, default 0.5), and counts only once the new policy has its own fresh window of at least 100 calls over at least 48 hours within the 2% threshold. A row with a malformed pin is not counted. guard readiness and doctor show fresh and carried evidence separately. Reviewed effectiveness evidence is still pinned to the full adapter and policy version, so this change alone does not move the guard out of watching.
A memory note that names a dangerous command is recorded, not held (partial, #629). Writing a memory-markdown file (MEMORY.md, CLAUDE.md, CORTEX_MEMORY.md, or markdown under a .claude/memory/ or memory/ folder) with no shebang, whose plain prose names a dangerous-tier command such as privilege escalation, stopping a service, a firewall tool or wiping shell history, used to ask for approval where the guard was enforcing. Writing that file runs nothing, so it is now allowed at the sensitive tier and recorded with the matched signals. Unchanged: catastrophic forms in the prose still block; guard self-protection and sensitive-path names in the prose still ask; a memory file at a sensitive or guard-owned path still asks; shebang bodies and every script-like path are handled as before; and running the file is folded and scanned as before wherever the plane can read it. The guard does not tell English prose from a bare command, so a note made only of a command line is writable too. On the Hermes REST plane, which has no source resolver, running such a note is treated as an opaque script and allowed at the sensitive tier unless the typed command is itself dangerous. This is not general command safety; the written-script and Bash-plane parts of #629 are not addressed.
The Claude Code hook reads a relative script from the call's directory (partial, #634). The hook resolved a relative invoked script, and checked its reviewed-script pin, against its own process directory. When a wrapper changed directory first, it could read an unrelated file of the same name, or none. It now uses the call's own working directory when that is an absolute path, and falls back exactly as before otherwise. Where the guard is enforcing, a call can now ask where it was allowed, or be allowed where it asked. The OpenClaw plugin is not changed: with no working directory, or a relative one, it still resolves against the gateway's directory. That case and the original cross-host discrepancy reported in #634 remain open.

Also in 5.7.0

The README, upgrade guide and doctor no longer overstate the PERSONAL boundary (#729): they describe the lane limits above instead of saying private notes never reach automated turns. That is wording only.

Read the changelog →

Full 5.7.0 release notes on GitHub →

Built by Drakon Systems.