CLARE CODE BUG31 March 20268 min read

Your Skill's Security Hooks Vanish in Claude Code Fork Mode

A silent bug in Claude Code: when a SKILL.md defines PreToolUse hooks alongside context: fork, the hooks are silently not propagated to the forked subagent. Your security guardrails disappear without warning.

There is a silent bug in Claude Code that security-conscious skill authors need to know about: if your skill uses PreToolUse or PostToolUse hooks for sandboxing, and the skill runs in fork mode, those hooks do not propagate to the forked subagent.

The hooks are defined. They are parsed. They just don't run.

The Bug: Issue #40630

GitHub issue #40630 was filed by a developer who noticed the discrepancy while auditing their own skill. Their SKILL.md frontmatter set both context: fork and a PreToolUse hook that rejected any Bash tool call without an allowlist match. In fork mode, the hook condition was never evaluated — the subagent ran with unrestricted Bash access.

They verified the model: key in the same frontmatter worked correctly, proving it wasn't a frontmatter parsing failure. Only the hook entries are dropped.

What Fork Mode Actually Does

context: fork in SKILL.md tells Claude Code to spin up an isolated subagent for that skill's execution. It's intended as a sandboxing mechanism — a way to keep an agent's side effects from contaminating the parent session.

The intent is sound. The implementation has a gap. When the parent session hands off execution context to the forked subagent, it does not copy hook registrations from the SKILL.md frontmatter. The subagent starts fresh — with no hooks.

Why This Is a Security Issue

Hooks are the primary mechanism in Claude Code for restricting what an agent can do without modifying the underlying model prompt. A PreToolUse hook that blocks Write calls to paths outside /tmp, or rejects Bash commands not on an allowlist, is a real security boundary.

When that hook silently disappears in fork mode, the skill author's security model breaks invisibly. The skill appears to be sandboxed. It is not. And because there is no warning, no log entry, and no runtime error, a developer has no way to detect this from the outside.

Three Scenarios Where This Matters

1. Skills that shell out to third-party tools. If a skill runs an npm package, Python script, or compiled binary via Bash, and the hook blocking unexpected arguments is gone, the shell call is unguarded. A dependency with a malicious update now has no interception point.

2. Skills that write files. A hook that restricts write paths to a workspace directory becomes inoperative. The forked subagent can write anywhere the process has permission to write, including ~/.claude/, SSH keys, shell configs.

3. MCP skills with forked execution. An MCP server that requests fork mode for parallelism loses any tool-level restrictions the skill author defined. If the MCP server is compromised or updated to a malicious version, the hooks that were meant to limit its reach are not present.

What SkillShield Detects

SkillShield's static scanner parses SKILL.md frontmatter and flags this combination:

context: fork
hooks:
  PreToolUse: ...

When this pattern appears, the scanner emits a HOOK_FORK_PROPAGATION_RISK warning:

HOOK_FORK_PROPAGATION_RISK: This skill defines PreToolUse hooks and uses context: fork. Due to a known Claude Code bug (issue #40630), hooks are not propagated to forked subagents. Any security restrictions defined via hooks will not apply during fork execution.

What to Do Right Now

If you maintain any skills that combine context: fork with security hooks:

  1. Run skillshield scan . against your skills directory. The scanner flags the HOOK_FORK_PROPAGATION_RISK pattern.
  2. Audit your fork-mode skills manually. For each skill with context: fork, verify the hooks are not load-bearing for security. If they are, disable fork mode or replace hooks with allowedTools restrictions.
  3. Watch issue #40630 for a fix from Anthropic. When a patch ships, re-scan and remove the workarounds.
  4. Do not rely on hooks as your only security boundary for any skill that might run in fork mode, even accidentally. Treat hooks as defence-in-depth, not the primary lock.

The Broader Pattern

The fork mode hooks bug is a specific instance of a general problem with agent security: isolation primitives and security primitives can interact in ways that silently cancel each other out. Fork mode was designed for isolation. Hooks were designed for control. When they interact, neither property is guaranteed.

This is precisely why pre-install scanning exists — not because every skill is malicious, but because the trust model breaks silently. A skill that worked correctly last week may run without guardrails this week because of a Claude Code update, a dependency change, or a frontmatter combination that hits an undocumented edge case.

Detect the HOOK_FORK_PROPAGATION_RISK Pattern

SkillShield scans your SKILL.md files and flags the dangerous combination of fork mode + security hooks before you deploy.

Scan Skills Free