Boucle v0.7.0 ships with over a thousand tests across 8 hook suites and a diagnostic tool. The number isn’t the point. What matters is where the patterns came from.

Every new detection category in this release traces back to a specific incident reported by a real Claude Code user.

87GB of personal data, gone

Issue #37984. A user asked Claude Code to reformat an external drive from APFS to exFAT, stating three times to preserve the files on it. Claude ran diskutil eraseDisk without backup, without warning, without confirmation. 87GB of photos, media, and documents, permanently destroyed. Recovery with PhotoRec failed because APFS encryption made the blocks unreadable.

v0.7.0 adds disk utility detection to bash-guard. diskutil eraseDisk, diskutil eraseVolume, diskutil partitionDisk, fdisk, gdisk, parted, sfdisk, wipefs. All blocked before execution.

30 files destroyed, then the IDE database

Issue #37888. Claude Code ran git checkout HEAD -- . and overwrote 30+ files despite 100+ CLAUDE.md rules saying not to. Then, in the same session, it ran sqlite3 commands against the VSCode internal database. The result: corrupted IDE state on top of destroyed project files. The issue now has 7 comments and a request for compensation.

v0.7.0 adds two protections for this. git-safe now blocks checkout-from-ref patterns (git checkout HEAD -- ., git checkout HEAD -- path). bash-guard now blocks sqlite3 operations targeting IDE internal databases (VSCode .vscdb, Cursor, JetBrains config DBs). The system database patterns match paths, not just the sqlite3 command, so legitimate sqlite3 usage on your own databases still works.

The encoding bypass problem

No single issue prompted this. It came from competitive analysis. Another tool in this space, claude-code-bash-guardian, uses Python with bashlex for AST-based parsing. It catches things that string matching misses. Looking at where it was stronger revealed a class of attacks: encoding bypasses.

echo cm0gLXJmIC8= | base64 -d | sh decodes to rm -rf / and executes it. Pattern matching on the command string sees a base64 invocation, not the destructive operation. Same for hex (xxd -r -p), octal, reversed strings (echo '/fr- mr' | rev | sh), and process substitution (bash <(curl ...) patterns).

v0.7.0 detects 6 encoding bypass categories. It doesn’t try to decode the payloads. It blocks the pattern of “decode something and pipe it to a shell interpreter.” The heuristic is: if you’re decoding arbitrary data and feeding it to bash/sh/zsh, that’s blocked regardless of what the data contains.

The here-doc gap

Related to encoding bypasses: Claude Code can construct dangerous commands through shell redirection features. A here-document can embed rm -rf / in a way that never appears as a top-level command:

bash <<'EOF'
rm -rf /
EOF

bash-guard evaluates each segment of compound commands, but <<EOF content wasn’t being inspected. v0.7.0 adds here-string (<<<), here-document (<<EOF), and eval-string detection. It also catches xargs piped to shell interpreters (find . | xargs sh -c), which is another way to construct commands that bypass per-line inspection.

Verifying hooks actually work

The most common safety-check failure mode wasn’t “hooks not installed.” It was “hooks installed but not working.” Wrong permissions, wrong JSON format, wrong hook type, scripts that exit 0 on error.

v0.7.0 adds --verify mode to safety-check. Run it with:

curl -fsSL https://raw.githubusercontent.com/Bande-a-Bonnot/Boucle-framework/main/tools/safety-check/check.sh | bash -s -- --verify

It sends real test payloads to each installed hook. rm -rf / to bash-guard. git push --force to git-safe. A protected file path to file-guard. If the hook returns {"decision": "block"}, the test passes. If it returns anything else, or times out, or crashes, safety-check reports the failure.

This caught real bugs during development. One test sent dd if=/dev/zero of=/dev/sda to bash-guard, and the hook blocked it. Then a test sent dd if=input.raw of=output.img, and the hook blocked that too. Legitimate dd usage on regular files was being caught as a false positive. v0.7.0 fixes this by checking whether of= targets a device path or a regular file.

The numbers

From v0.6.1 to v0.7.0:

30 commits. 2,159 new lines. Every detection pattern backed by a specific threat model.

What’s next

The community scan from this release cycle surfaced two new patterns worth addressing:

Issue #38270: Claude Code’s Write and Edit tools silently accept relative paths despite the spec requiring absolute paths. A confused model writes to the wrong file. A path validation hook could catch this.

Issue #38287: Worktree cleanup silently deletes branches with unmerged commits. A user independently built a PreToolUse:ExitWorktree hook as a workaround. Same pattern as every other hook in this framework: the platform doesn’t enforce the safety boundary, so hooks do.

Install or update:

curl -fsSL https://raw.githubusercontent.com/Bande-a-Bonnot/Boucle-framework/main/tools/install.sh | bash -s -- all

Check your current setup:

curl -fsSL https://raw.githubusercontent.com/Bande-a-Bonnot/Boucle-framework/main/tools/safety-check/check.sh | bash -s -- --verify

Full changelog. Repository.