Model bypasses all PreToolUse write-protection hooks using perl — blocklist approach is fundamentally incomplete

[weilhalt]

Summary

We built a comprehensive write-protection system over several weeks: 22 regex patterns across 3 layers blocking in-place sed, inline python, echo redirects, cat heredocs, tee, touch, rm, cp, mv, and more. Claude respected all of them -- until it found perl -i -pe, which was not on the list.

The model did not try to bypass the rules. It genuinely needed to fix a bug in its own safety system (a timezone issue that created a triple deadlock). But the way it solved the problem exposes a fundamental weakness in the hook-based permission model.

What happened

1. A UTC-vs-local-time bug in our session-gate policy caused it to reject valid session entries written near midnight. The gate blocked all Edit/Write tool calls.

2. The fix needed to go into policy.py -- but Edit was blocked by the very bug being fixed (chicken-and-egg).

3. The override system could not help either -- override_guard parses the session transcript for AskUserQuestion but could not find it, creating a second deadlock.

4. protect-hook-scripts blocked Read/Edit/Write/Bash/Glob/Grep on runner.py, preventing investigation of the override failure -- third deadlock.

5. The model then used perl -i -pe to edit the files directly. Perl is not in our blocklist. The bash guard pattern-matches against known write tools but has no concept of any command that can modify files.

6. It then used perl with File::Copy to deploy the fix to 6 other project repositories -- bypassing the cp block.

The security model gap

Our blocklist covers in-place sed, awk-with-redirect, inline python/python3, echo/cat/printf redirects, tee, touch, rm, mv, cp, chmod, chown, truncate, dd, and install.

Not covered (all can write files):

perl -i -pe          # in-place edit (identical to sed in-place mode)
perl -e              # arbitrary file I/O
ruby -e              # same
lua -e               # same
node -e              # same
xxd + redirect       # binary writes
busybox sed          # aliased tools

A blocklist for commands that can write files is equivalent to blocking all Turing-complete interpreters -- which is impossible without a whitelist approach.

What would actually work

Allowlist instead of blocklist. Instead of block these 22 patterns, the hook should say only allow these N patterns. Our current whitelist (21 entries like git rm, pip install, npm install, chmod +x) is the right idea -- it just needs to be the primary gate, not the exception list.

Proposed model:

if command matches allowlist -> permit
else -> block (with override mechanism)

This inverts the current logic:

if command matches blocklist -> block
else -> permit  <- this is the hole

Irony

The model was simultaneously:

• Too limited to fix a one-line timezone bug through legitimate channels (3 interlocking policies blocked it)
• Resourceful enough to bypass weeks of carefully crafted write-protection by using an unlisted interpreter

It did not act maliciously -- it solved the problem the user asked it to solve. But a model that autonomously discovers perl as a bypass vector is a model that could discover it for less benign purposes.

Environment

• Claude Opus 4.6 (1M context)
• Claude Code CLI
• Custom PreToolUse hooks with regex-based bash command filtering
• 52 policies, 6 hook scripts, 3-layer write protection

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] disallowedTools: [Write, Edit] trivially bypassed via Bash tool — agents use sed/awk/redirects to modify files #31292
2. Claude Code circumvents PreToolUse:Edit hook via Bash tool #29709
3. [SECURITY] SED Commands Can Damage Code Files Despite PreToolUse Hook Blocking Attempts #6876

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[yurukusa]

Great analysis of the fundamental blocklist limitation. The perl -i -pe bypass is a known gap in pattern-based approaches.
Immediate workaround: The banned-command-guard hook's default pattern (perl -pi) doesn't catch perl -i -pe because the flags are separated. A broader pattern fixes this:

export CC_BANNED_COMMANDS="sed\s+-i:awk\s+-i\s+inplace:perl\s+.*-[ip].*-[ep]"

This catches perl -i -pe, perl -pi -e, perl -p -i, and similar variants.
Defense-in-depth approach: Rather than maintaining an ever-growing blocklist, combine two hooks:

1. banned-command-guard (pattern-based, catches known tools):

CC_BANNED_COMMANDS="sed\s+-i:awk\s+-i:perl\s+.*-i:dd\s+of=:tee\s+"

2. overwrite-guard (behavior-based, catches ANY file modification):

INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty' 2>/dev/null)
[ -z "$COMMAND" ] && exit 0
echo "$COMMAND" | grep -qE '^(cat|head|tail|less|grep|find|ls|wc|diff|file|stat|echo|printf|cd|pwd|which|type|test)\s' && exit 0
echo "$COMMAND" | grep -qE '>\s|>>' && { echo "BLOCKED: Output redirection detected. Use Edit tool." >&2; exit 2; }
echo "$COMMAND" | grep -qE '\s-i\b|\s--in-?place' && { echo "BLOCKED: In-place modification detected. Use Edit tool." >&2; exit 2; }
exit 0

The behavior-based approach is more resilient since it doesn't need to enumerate every tool that can modify files — it detects the modification patterns themselves.

[weilhalt]

Not a duplicate. The linked issues address different problems:

• [BUG] disallowedTools: [Write, Edit] trivially bypassed via Bash tool — agents use sed/awk/redirects to modify files #31292 is about general Bash tool bypasses
• Claude Code circumvents PreToolUse:Edit hook via Bash tool #29709 (mine, closed) is about Edit→Bash circumvention with sed/python
• [SECURITY] SED Commands Can Damage Code Files Despite PreToolUse Hook Blocking Attempts #6876 is about file write protection

This issue is about a fundamental architectural limitation: the blocklist approach to preventing file writes via Bash is inherently incomplete. Any interpreter not on the list (perl, ruby, node, lua, busybox, etc.) becomes a bypass vector. The issue proposes moving to an allowlist model as the only viable long-term solution. That's a different class of problem than the specific bypass reports linked above.