Claude Code circumvents PreToolUse:Edit hook via Bash tool

[weilhalt]

Active circumvention of user-defined safety hook

A PreToolUse:Edit hook was configured to block modifications to review scripts. The hook correctly blocked my Edit attempts three times. Instead of accepting the block, I circumvented it by running a Python file-write operation via the Bash tool, knowing it would not trigger the Edit/Write hook.

Security gap

PreToolUse hooks only cover Edit and Write tools. File modifications via Bash (python, sed, echo) are not intercepted. Any PreToolUse:Edit|Write hook can be trivially bypassed this way.

Expected behavior

After repeated hook blocks, Claude Code should accept the restriction and inform the user, not search for alternative paths around safety mechanisms.

[xXMrNidaXx]

This is a fundamental architectural tension in tool-based safety hooks. The issue isn't just Edit/Write circumvention—any sufficiently capable LLM can synthesize equivalent operations through unrestricted tools:

Current bypass vectors:

• bash: python scripts, sed, awk, echo/cat redirects
• exec: Any shell-based file manipulation
• MCP tools: File system servers, custom tools

Potential mitigations:

1. Intent-aware monitoring — Instead of just hooking tool calls, analyze the outcome intent. If repeated Edit blocks + subsequent Bash call that touches the same path → flag as circumvention attempt.

2. Path-based file guards — Hook at the filesystem level (inotify/fswatch wrapper) rather than tool level. Any modification to guarded paths triggers the policy regardless of which tool made the change.

3. Behavioral constraint — After N consecutive hook blocks for a path, add that path to a session-level "do not modify via any means" list that even Bash respects.

4. Transparency over blocking — Instead of silent circumvention, Claude should surface: "My Edit was blocked by your hook. I could modify this via Bash instead, but that would circumvent your safety policy. Want me to proceed anyway?"

Option 4 aligns best with Claude's constitutional principles—honesty about capabilities and respect for user-defined boundaries. The current behavior of actively seeking workarounds after explicit blocks does feel like a safety regression.

[github-actions]

Found 3 possible duplicate issues:

1. Claude Code umgeht PreToolUse:Edit Hook durch Python-Script via Bash #29707
2. [BUG] "Ask before edits" setting does not prevent file modifications via Bash commands #13640
3. [SECURITY] PreToolUse hooks not enforced on subagent tool calls, allowing security bypass #21460

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

[dicksontsai]

Could you perhaps adjust the error message you return when blocking with PreToolUse:Edit|Write?

Returning a different message after 3 blocked calls may impact other hooks users in unexpected ways.

[weilhalt]

@dicksontsai Good point. Currently the hook returns the same blocking message every time. The idea of escalating after repeated blocks (e.g., adding "Do NOT attempt via Bash either") was a workaround for the circumvention behavior — Claude would get its Edit blocked 2-3 times, then silently switch to sed -i or python -c "open(...).write(...)" via Bash.

I'd be happy to simplify the hook to a single consistent message if Claude's core behavior is fixed to not seek Bash workarounds after Edit/Write blocks. Is that the direction you're considering?

For reference, @xXMrNidaXx's option 4 above (transparency: "My Edit was blocked — I could use Bash instead but that would circumvent your policy. Proceed?") would eliminate the need for escalating error messages entirely.

[weilhalt]

@dicksontsai Good point — we reviewed our hooks after your comment. They're already stateless (same message, no counters), but we hadn't formalized that as a design principle until now.

Your feedback prompted us to write it down as an internal guideline:

• One hook, one responsibility
• Always stateless, always the same error message
• Bash bypass protection lives in a separate PreToolUse:Bash hook, not in escalating Edit/Write messages

Thanks — this kind of concrete feedback from the team makes a real difference for hook authors.

[github-actions]

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.