Ironheights 0.3.0: running next to the security tools you already have
Ironheights 0.3.0 is on npm. Few OpenClaw setups run one security tool. A typical one has a vetting skill that the agent follows, perhaps a guard plugin, a scanner command such as Cisco's skill-scanner, and a secret scanner in a pre-commit hook. Adding one more tool should not turn into a puzzle about which one blocked a tool call, or which one rewrote a file. This release adds a way to find out. This post covers what is new in plain language, how to try it, and what it does not do. None of it makes a skill or an agent safe.
What is new in one minute
ironheights coexistlists the other security tools it can see on your machine and reports where they overlap with Ironheights. It reads files only and changes nothing.- The guard plugin takes a
prioritysetting, defaults to 80, and logs one line at startup when it sees another security tool. - When
scanmeets a skill named like a known security tool, it adds a note and lowers confidence on that skill's Markdown injection and credential findings by one step. It never allowlists anything. ironheights doctorprints a one-line summary.
The full list is on the features page, and the design notes are in the repository's coexistence document.
Five ways two security tools get in each other's way
Most pairs of tools never touch. These are the cases where they do:
- Two guards on one tool call. OpenClaw's plugin documentation says
before_tool_callhandlers run from the highest priority down and that a block ends the chain. If two plugins can block, the higher one decides. The other never sees that call, so its log is missing it, and you can see two different block reasons on different days. - Two owners of the same files. A tool that restores or removes files and an integrity baseline that expects them to stay put can disagree about which copy is right.
- One shared folder. Two tools that write logs or state into the same directory can overwrite each other.
- Double network use. Two scanners that both contact ClawHub or a vendor cloud send the same skill twice, and one of them may upload its content.
- Competing instructions. Several skills that tell the agent to vet every install can each give a different answer. An instruction in a skill is advice to the model, not enforcement, and the model picks one.
Find out what you have
npx ironheights coexist
The command reads six kinds of source: your OpenClaw config, plugin manifests, skill and hook folders, known state folders, PATH, and the CI and pre-commit files of a project you name with --repo. For each other tool it recognises, it prints the file that showed it. Then it prints overlaps as IH-COEX-001 to IH-COEX-011, each with a severity and a fix. This is real output from a test machine, trimmed:
Other security tools detected: 3
- clawdefender [skill-scanner] present, medium confidence
- guard-scanner [runtime-guard] enabled, high confidence, guards tool calls
- skill-vetter [instruction-skill] present, medium confidence
Conflicts and notes: 2
[medium] IH-COEX-001 More than one tool-call guard is active
fix: Pick one tool to own blocking. Keep Ironheights in monitor mode
(the default) if the other guard enforces.
[low] IH-COEX-008 Several skills tell the agent to scan or vet installs
For scripts and CI there is --json, which follows a published schema, and --fail-on medium, which exits 1 when a finding reaches that severity. The command does not run any of the tools it finds. It does not call the network and it does not write a file, so it is safe to run on a machine you would rather not disturb.
What it does not do. It cannot see what a running Gateway has loaded. It finds tools by file, folder and name, so a tool it does not list, or one that was renamed, is missed. A name can be copied by anyone, so a hit means that something with that name is present, not that it is the real tool.
Two guards on one tool call
The Ironheights guard is an OpenClaw plugin that checks a short list of risky tool calls. By default it runs in monitor mode, which logs and never blocks. In 0.3.0 it also runs at priority 80, and you can change that:
{ "plugins": { "entries": { "ironheights-guard": { "enabled": true, "config": { "mode": "monitor", "priority": 80 } } } } }
Higher numbers run first, and OpenClaw's own default is 0. The guard returns only a block or an allow. It never rewrites a tool call and never asks for approval, so it cannot collide with another plugin's rewrite or prompt. Every block reason starts with ironheights:, so you can tell whose block you are reading. Its files live under ~/.ironheights, away from other tools' folders, and coexist raises IH-COEX-005 if you point IRONHEIGHTS_HOME at a shared directory.
The advice that follows from this is simple. If another guard already enforces, leave Ironheights in monitor mode, keep its scanner and its integrity checks, and let one tool own blocking. If you want Ironheights to enforce instead, coexist tells you what else would also block.
What it does not do. Priority sets the order, not who is right. The hook runs inside the agent, so it is not a sandbox, and a skill that can edit your OpenClaw config can turn it off. The hook order described here follows OpenClaw's plugin documentation as checked on 11 October 2026, and a later OpenClaw release can change it.
Security skills look like attacks, and attackers know it
A skill that vets other skills quotes injection strings and lists credential paths, because that is its job. A scanner flags those files. For the real tool that is a false positive. For a malicious skill that borrows the name, it is the ideal disguise. So 0.3.0 does the least it can.
If a scanned skill's folder or SKILL.md name equals a tool on Ironheights' list, scan adds a note: name match only, not verified. It lowers confidence by one step on injection and credential findings that sit in Markdown files, such as IH-INJ-001. Findings in scripts, config, binaries, network, obfuscation, persistence and exec rules are untouched. Severity, score, grade, verdict and exit code do not change, and nothing is hidden. If you decide to trust one copy, review it, record it with a baseline, or add a suppression that carries a written reason for that file and line.
coexist also checks the other direction. If your own config ignores or suppresses a path that carries the name of a security tool, it reports IH-COEX-010, because that is an allowlist by name.
What it does not do. A name match proves nothing about the files. The note helps you read findings. It is not a clearance, and a malicious skill that borrows a familiar name gets the same verdict as any other.
Where the list of tools comes from
The detector uses a list of known tools in the CLI's source. Each entry names the facts it relies on, such as the skill name, the plugin id, a command or a state folder, and carries a link to the page it was read from. We list a tool only after reading its listing, its repository or its package. Anything we could not read is not on the list. If a tool you use is missing, open an issue with a link to its public page. A missing tool is not found, and that is a limit of the list, not evidence that the tool is absent.
Try it
npx ironheights --version
npx ironheights coexist
Or install it once with npm install -g ironheights. If you would rather not install anything, the browser scanner runs the content rules on a pasted SKILL.md. It uses the 0.1.5 engine, so it does not run coexistence, grade, MCP, advisory or config checks. Those need the CLI. The public cases our rules are mapped against are in the tracker.
Numbers we did not change
The benchmark was measured on version 0.1.0 with a 20-skill synthetic corpus that we wrote, so it is a regression check and not a detection rate. We did not re-run it for 0.3.0 and we have not changed its figures. Coexistence detection is not part of those numbers, and we have not measured how often it misses a tool on real machines. Read the limitations page for the rest of what Ironheights cannot catch.
FAQ
Can I run Ironheights next to other security scanners?
Yes. Ironheights reads files and does not run other tools, and its guard stays in monitor mode unless you change it. Run ironheights coexist to see which other tools it can find and where they overlap.
Does coexist change my OpenClaw config?
No. It reads files and prints the exact change it suggests. You make the change yourself. It writes nothing and makes no network call.
If coexist reports nothing, are my tools compatible?
Not necessarily. Detection is heuristic, so a renamed or unlisted tool is missed, and the command cannot see what a running Gateway has loaded. A report with no findings is not proof that tools will not interfere.
Sources
- Ironheights 0.3.0 on npm, npm.
- Ironheights v0.3.0 release, GitHub, 11 October 2026.
- Ironheights changelog, GitHub.
- Running Ironheights next to other security tools, GitHub.
- Guard plugin and threat model, GitHub.
- OpenClaw plugin hooks, OpenClaw documentation.