[SECURITY] PreToolUse hooks not enforced on subagent tool calls, allowing security bypass

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/6305
2. https://github.com/anthropics/claude-code/issues/18950
3. https://github.com/anthropics/claude-code/issues/20946

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

This addresses a gap in the current hook architecture's security model. PreToolUse can block tool execution, but as you've demonstrated, this protection doesn't extend to subagents - any security boundary can be bypassed by spawning a Task.

Related: #18653 identifies another architectural gap where tool results cannot be sanitized before context ingestion. PreToolUse can block, PostToolUse can observe, but neither can transform content before it enters Claude's context window, leaving no mitigation layer against prompt injection via external content.

Together these suggest the hook system needs architectural attention for security use cases, not just point fixes.

Confirmed: Reproduced with E2E Test

I've empirically confirmed this issue while testing a PreToolUse-based safety plugin.

Test Results

Setup: Plugin-level PreToolUse hook with empty matcher (applies to all tools), deny rule for curl

Test: Spawned 2 subagents in parallel via Task tool - one to run find, one to run curl

Findings:

• ✅ Task tool successfully spawned subagents
• ✅ Plugin loaded (visible in debug log)
• ✅ Subagent attempted curl command
• ❌ NO hook execution - no evidence in debug logs
• ⚠️ curl blocked by sandbox network restriction, NOT by our deny rule

Conclusion: Plugin-level PreToolUse hooks do NOT fire for subagent tool calls.

Supporting Solution 1: Global Hook Enforcement

I strongly support the proposed "Global Hook Enforcement" solution - hooks configured in settings should apply recursively to all agents in the execution tree.

This is critical for security use cases where restrictions must be enforceable, not bypassable.

Resources

• Test code: https://github.com/Z-Lemke/llm-toolkit/blob/16083c9/plugins/safety-judge/tests/test_e2e.py
• Research: https://github.com/Z-Lemke/llm-toolkit/blob/16083c9/RPIV/research/subagent-hook-inheritance.md

Has there been any prioritization of this? This is a non-starter for subagent usage for us, as all guardrails are ignored.

This is a fundamental architectural issue — hooks run at the process level, but subagents spawn new processes that don't inherit hook configuration.

An alternative approach is scanning at the API/middleware layer rather than relying on hooks. Sentinel AI takes this approach — it can run as:

1. MCP safety proxy — sits between Claude and any MCP server, scanning all tool calls regardless of whether they come from the main agent or a subagent:

``json
{
"mcpServers": {
"safe-server": {
"command": "sentinel",
"args": ["mcp-proxy", "--", "your-mcp-server"]
}
}
}
``

1. API middleware — wraps the Anthropic/OpenAI client, scanning every request and response before it reaches the model

Since these approaches operate at the transport layer, they're immune to the subagent bypass — the scanning happens on every tool call, regardless of which agent initiated it.

The hook system is still valuable for quick policy enforcement, but for security-critical scanning, an external safety layer that can't be bypassed by spawning subprocesses is more robust.

This is a real gap. We work around it by enforcing at the shell execution boundary rather than the tool call boundary.

Our hook (https://github.com/tech-and-ai/claude-rule-enforcer) intercepts commands at the Bash tool level. Since every subagent ultimately executes through the same shell, enforcement applies regardless of which agent tier spawned the command.

Two layers: L1 regex for instant blocks (<10ms), L2 LLM review for context-dependent decisions. The architecture means even if PreToolUse doesn't fire for subagents, the gate still catches destructive commands.

Yikes, my hooks aren't protecting me. This is a serious issue.

Please try the CRE https://github.com/tech-and-ai/claude-rule-enforcer

Yikes, my hooks aren't protecting me. This is a serious issue.

I built something for exactly this. CRE (Claude Rule Enforcer) is a two-layer enforcement system that sits between the agent and the OS via pre-tool hooks.

L1: regex gate, blocks dangerous patterns instantly (<10ms). fork bombs, disk writes, force push, production SSH.

L2: LLM reads the conversation and checks "did the user actually ask for this?" if no user approval exists, it blocks. no retry bypass. the user has to explicitly say "yes do it" in chat.

It also self-protects. the agent cannot turn CRE off even if instructed to. hooks auto-restore if tampered with.

It works with OpenClaw's new tool:pre hooks, plus Claude Code, Cursor, Windsurf, Copilot, Codex, Amp. ships as an MCP server too for the intelligence layer.

open source (BSL 1.1): https://github.com/tech-and-ai/claude-rule-enforcer
site: https://ai-cre.uk

I've also reproduced this issue.

In addition, the PreToolUse and PostToolUse hook payloads don't include the calling agent_id. I'd like to have conditional logic for how the PreToolUse and PostToolUse hooks perform depending on which subagent called the tool. To accomplish this, I'm currently tracking the agent_id returned in the SubagentStart event payload and mapping it to my specified subagents in .claude/agents. Then, when a PreToolUse or PostTooleUse event arrives, I would check the agent_id in the payload, compare it to which of my agents are mapped to that id, and then run the conditional logic in my hook script.

Perhaps including agent_id in the payload of the PreToolUse and PostToolUse events should be a separate feature request... But then again, there are over 5000 of them right now, so... I'm slipping it in here! 😇

Claude wrote a bug report: worktree-permission-bypass-bug-report.md

I've reproduced the issue in a worktree using the new isolation: worktree mode.

Hook-level workaround: enforce security at user level + defense-in-depth
The root cause is that project-level .claude/settings.json hooks only bind to the agent that loads them. User-level hooks (~/.claude/settings.json) inherit to subagents because they're loaded at the Claude Code process level.
Move your security hooks from project settings to ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit|Bash",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/restrict-operations.sh",
            "timeout": 5
          }
        ]
      }
    ]
  }
}

User-level hooks fire for both the main agent and subagents.
Even with user-level hooks, a subagent can still be given overly broad permissions. This hook limits what files subagents can write:

INPUT=$(cat)
FILE=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty' 2>/dev/null)
[ -z "$FILE" ] && exit 0
SCOPE_FILE=".claude/agent-scope.txt"
[ -f "$SCOPE_FILE" ] || exit 0
SCOPE=$(cat "$SCOPE_FILE" | head -1 | tr -d '\n')
[ -z "$SCOPE" ] && exit 0
case "$FILE" in
    ${SCOPE}*) exit 0 ;;
    *)
        echo "BLOCKED: $FILE is outside agent scope ($SCOPE)." >&2
        exit 2
        ;;
esac

Then set scope per project: echo "src/" > .claude/agent-scope.txt
This is a workaround. The proper fix needs Claude Code to propagate hook bindings to all agents in the execution tree. But user-level hooks + scope files cover the most common bypass vectors.

Signet is now available on the official Claude Code plugin marketplace:

/plugin install signet@claude-plugins-official

Every tool call gets Ed25519-signed and appended to a hash-chained audit log at ~/.signet/audit/. This covers all agents in a session, including subagents that might bypass PreToolUse hooks.

Query the trail:

signet audit --since 1h
signet audit --verify # verify hash chain integrity

Not a replacement for fixing hook inheritance — but a useful defense-in-depth layer while that gets resolved.

https://github.com/Prismer-AI/signet

We tested both v2.1.22 (the release from the day this was filed) and current main: in both, a settings.json PreToolUse hook matching Write that exits code 2 fires and blocks when a subagent spawned via Task calls Write, identically to the main agent.

A note on the project-vs-user-level workaround mentioned upthread: both .claude/settings.json and ~/.claude/settings.json merge into the same startup snapshot, so there's no difference between them for subagent inheritance.

Related improvement since this was filed:
• v2.1.69+: hook payloads now include agent_id (set for subagent calls, absent for main-agent calls) and agent_type, so your hook script can branch on which agent made the call. Addresses @mathnathan's ask and #16126.

Thank you @dicksontsai !

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.