[Docs] Clarify whether PreToolUse hooks apply to sub-agent (Task/Agent) tool calls, and managed-settings tamper-resistance

Open 💬 0 comments Opened Jul 14, 2026 by ktimesk1776

What's unclear

The hooks documentation does not state whether a PreToolUse hook defined in
user/project/managed settings fires when a sub-agent (spawned via the Agent/Task
tool) makes a tool call — or only on the main session's tool calls.

This matters for safety hardening: a common real-world failure mode for agentic
coding tools has been a sub-agent taking a destructive action (e.g. a delete or
bulk API call) that the parent session's guardrails would have caught. If a
PreToolUse guard hook does not cover sub-agent tool calls, that is a coverage gap;
if it does, that guarantee should be documented explicitly so operators can rely on it.

Requests

  1. Document explicitly whether PreToolUse (and PreToolUse-equivalent) hooks

intercept tool calls made by sub-agents, not just the main session.

  1. If they do not currently cover sub-agents, consider making guard-class hooks

apply to sub-agent tool calls (or provide a managed setting to enforce this),
since the sub-agent path is the one most likely to bypass an operator's safety net.

  1. Clarify the tamper-resistance guarantee for managed settings: the precedence docs

state managed settings "cannot be overridden," but it isn't documented whether a
session running as a privileged user could modify the managed-settings file itself
(e.g. via a hook or Bash write) — i.e. whether the guarantee is enforced in-app or
relies solely on OS file permissions on the managed path.

Environment

Claude Code on macOS. Filing as an operator hardening a machine-wide destructive-action
safety layer; verified the managed-settings precedence and permissions.deny features
exist and work — this issue is specifically about the two points above, which the docs
don't currently settle.

View original on GitHub ↗