Three months ago, I configured hooks for my Claude workflow I was building to supercharge my work.

I added a PreToolUse block on dangerous shell commands so nothing destructive could run without being checked first.

I set up a PostToolUse tracker so every file change and commit would be logged automatically.

And I defined all of this in the main configuration file (~/.claude/settings.json), which is where the documentation told me to put it.

By the time I was done, I was really excited to use this. It was working great during my initial testing.

Then I planned to scale the workflow to use subagents in parallel and surprisingly none of the hooks fired even once.

Here is what had happened.

The subagents ran shell commands, wrote files, and executed git operations. It was literally doing everything the hooks were supposed to catch. When I checked the compliance logs after they finished, every counter showed zero. Not a single hook had fired. I spent an hour going through the configuration looking for a syntax error.

I was sure that it wasn’t the syntax. I also checked and the pattern matches were correct as well. The issue was with the main configuration itself where I had defined everything.

To understand why, you need to understand how hooks are scoped.

I got to learn that whenever you define a hook, it gets a scope where it lives and executes. The scope is the active environment where the AI is running and making tool calls.

When the AI processes a request inside that environment, it checks the hooks, runs the patterns, and enforces the rules. This is what made me feel like hooks can be a complete safety layer I can build into my workflow. I had this assumption in mind that any tool call that session makes goes through them first.

The problem is that subagents are not running in that environment.

I know it may sound confusing at first. I used to think the same that when a parent session spawns a subagent, the subagent inherits the parent’s configuration the way a child process inherits environment variables.

But that is not how AI agent workflows actually work. A subagent is a completely isolated context window. It receives the task instructions from the parent. It receives nothing else. The hooks the parent defined are not executed because the subagent is not running in the parent’s session.

So when my subagents ran, they had no hook configuration at all. Every shell command, every file write, every git operation executed without any of the checks I had built.

Now that I understood the problem, the fix was simple.

Each subagent definition file the .md files inside .claude/agents/ accepts a hooks: block at the top, which is a YAML section where you define the same PreToolUse and PostToolUse rules.

This simple change gave me a peace of mind and I can see every hook blocking the requests I never approved. Now I am experimenting this technique even more to take it to an advanced level.

I will share more on it in the next post. Stay tuned.