failproofai 1.0.3
If you're on 1.0.2, check this first
failproofai policies --install <policy> --cli <x> stopped writing hook
config after the first time it ran on a machine. It exited 0 and printed a
reassuring Enabled … from pack line but wrote nothing, and that CLI ran with
no enforcement at all.
The first install always worked, which is why it survived testing. Only the
second one onward was dead. So the people affected are those who set up one
agent CLI and then added another the second one has been unguarded ever
since.
Check what's actually wired:
failproofai policiesFix any CLI that's missing:
npm i -g failproofai@latest
failproofai policies --install <policy> --cli <the-missing-one> --scope userYou should see Failproof AI hooks installed for … and a Settings: path. If
you only see Enabled … from pack, you're still on the old version.
Cause: the first install downloads the FailproofAI/policies pack, which
declares every builtin by name. From then on a name like block-sudo resolved
as a pack policy rather than a builtin, and hit a shortcut written for
third-party packs "they only named pack policies, so flip the switch and
stop" which returned before writing any settings, discarding --cli,
--scope and --custom on the way out. That shortcut now applies only to names
failproofai doesn't ship itself.
Introduced in 1.0.2 (#738). Fixed in #760.
Also in this release
Three fixes to the daily integration suite, which had been reporting working
CLIs as broken enforcement while the fault was here. None of them change what
the package enforces:
- a denied-and-honoured route-around is no longer scored as a silent-allow
- the normalization-drift detector no longer fires on payloads that mapped
correctly - openclaw enforces in the suite for the first time — five separate silent
failures, including thatopenclaw agent --localnever dispatches plugin
hooks at all
Verified across all 12 supported agent CLIs against live models,
daemon-configured: all 12 enforcing.