perf(hooks): Windows process-creation tax makes the hook set unusable - 1,778 timeouts / 20.6 hours blocked over 9 days

[kyle-sexton]

Warning

Three claims in the original body are superseded. See the correction comments. Do not work from the original acceptance criteria — they conflict with the marketplace hook budget and with the child issues.

Superseded: the acceptance criteria

The original body proposed "median PreToolUse hook-stack wall-clock under 2 s" and "no hook exceeds 5 external process spawns", while every child issue says "no more than 2 spawns". Three different bars coexisted. The binding bar is docs/conventions/hook-budget/README.md (adopted #1809, surfaced via .claude/rules/hook-budget.md):

Surface	Budget
Per tool call (PreToolUse + PostToolUse, one matcher)	<= 1 s typical, <= 2 s worst-case
Per turn (Stop / notification-shaped)	<= 500 ms

Measured as parallel wall time, not the sum. Note the original "under 2 s per hook" let a single hook consume the entire worst-case budget for the whole set — with 8 guardrails hooks on the Bash matcher, all could "pass" while the set failed the convention several times over. The Stop-event children were 4x over the per-turn ceiling under the old criterion.

Use instead, for every child:

• Spawn count on the common path, reported before and after, measured by PATH shim (the drift-immune criterion).
• The hook's measured share, by the convention's method (EPOCHREALTIME around direct invocation, >= 10 runs, concurrent launch), stated in the plugin README per hook-budget Rule 1.
• The always-on set stays within <= 1 s typical / <= 2 s worst-case per tool call, or <= 500 ms per turn, reported alongside the spawn-cost baseline at measurement time.

Matcher-narrowing work should additionally cite docs/conventions/hook-precision/README.md, which owns what a hook fires on.

Superseded: "they serialize"

The original body said hooks "serialize" on one tool call. The convention states Claude Code runs matching hooks in parallel — "the wall is the max of the set under spawn contention, not the sum." The transcript evidence (up to 8 hooks timing out against one toolUseID) shows they contend, which is not the same as serializing. The corrected reading: parallel dispatch, with wall-clock set by the slowest hook plus contention among them. That is also why hook cost must never be presented additively.

Superseded: the flat spawn cost and the timeout

• Spawn cost is bimodal (180-2,841 ms, 15.7x spread, at 501 concurrent processes), not the flat 661/872/908 ms quoted in the body. Never quote a spawn figure without concurrent_processes_at_sample.
• "Against a 15 s timeout" is wrong as a universal. Actual configured timeouts: source-control 15 s, guardrails 60 s, context-guard 60 s, disk-hygiene Stop 20 s, claude-ops Stop 10 s, autonomy Stop 15 s.

Method pin (was missing)

Transcript counts: hook_cancelled attachment records with timedOut: true, reading durationMs / timeoutMs / hookName / command, across 236 session files under ~/.claude/projects/**/*.jsonl, 2026-08-23 to 2026-08-31.

The static call-site counts in the original body do not reproduce and should be treated as indicative only. An independent pass on shipped guardrails 0.29.24 yields, for block-dangerous-git.sh, 184 (with comments) / 163 (lines-with-match) / 44 (comment-stripped) — none equal to the published 127. The ordering holds under every method, so #3529's headline stands, but absolute counts need the exact command and version pinned before being quoted.

Prior art, and the delivery constraint

• guardrails: recover the PreToolUse spawn-reduction work from the closed #1385 #1403 / fix(guardrails): restore PreToolUse enforcement — guards were killed at their timeout #1385 (both closed) already contain hook::jq_fields, strip_quoted_spans, a deferred git rev-parse probe, a 65-spawn-per-Bash-call census, and a 437 ms unit price — plus the reason fix(guardrails): restore PreToolUse enforcement — guards were killed at their timeout #1385 did not merge: four contract-test regressions, two failing open.
• hook-utils.sh exists in 17 copies across plugins/*/hooks/, delivered by scripts/sync-hook-utils.sh. Changes go through that script with all copies verified identical.
• Validate with scripts/affected-tests.sh --run.

---

Original body — SUPERSEDED by the block above. Kept for the record; do not work from its numbers or checklists.

Summary

On a Windows host, the marketplace hook set blocks the agent loop for hours per day. Over a 9-day window on one machine: 1,778 hook timeouts totalling 74,123 s (20.6 hours) of blocked wall-clock, mean 41.7 s each against a 15 s timeout.

The scripts are not the problem. Process creation on this host costs 0.3-0.9 s per spawn. Every hook pays that toll once for its own shell and again for each external command it invokes.

This is the parent issue for the root cause. Per-hook children are listed at the bottom.

Measured: process spawn cost

bash -c true                    x10 ->  6.614 s real  = 661 ms/spawn   (user time 0.090 s TOTAL)
bash --noprofile --norc -c true x10 ->  2.775 s real  = 277 ms/spawn
jq -n 1                         x10 ->  9.083 s real  = 908 ms/spawn
cmd.exe /c exit                 x10 ->  8.719 s real  = 872 ms/spawn

Two things to read off this:

1. User CPU time for 10 bash spawns is 0.090 s. ~99% of wall-clock is process-creation overhead, not script work. Optimizing script logic cannot fix this.
2. cmd.exe is as slow as bash. This is not MSYS/Git-Bash fork() emulation. It is native Windows process creation.

Healthy reference on Linux/macOS is ~3-5 ms/spawn. This host is ~150-200x slower.

Cost model for any hook: 0.66 s (its own bash) + N x 0.91 s (each jq). A hook making 5 jq calls costs ~5.2 s before executing a single line of its own logic.

Measured: fan-out per tool call

59 hook commands are registered across 16 events by 22 enabled plugins - 17 on PreToolUse, 22 on PostToolUse. They serialize:

hooks timing out on a single tool call:
  1 hook  -> 113 tool calls
  2 hooks -> 327
  3 hooks -> 146
  4 hooks ->  30
  5 hooks ->  34
  6 hooks ->  15
  7 hooks ->  12
  8 hooks ->   3

Every Bash, PowerShell, and Edit call pays the whole stack.

Measured: worst offenders

hookName || command, by timeout count, from transcript hook_cancelled attachments with timedOut: true:

  423x PreToolUse:Bash        PR body / pr-issue-linkage gate           avg 24.7s  max 115.3s
  418x PreToolUse:Bash        git worktree add nesting invariant        avg 26.0s  max 115.3s
  126x PreToolUse:Bash        commit subject / PR title convention      avg 70.5s  max 162.8s
  113x Stop                   unsurfaced hook failures                  avg 21.9s  max  74.1s
   82x PreToolUse:PowerShell  hook-bypass attempts                      avg 75.1s  max 134.1s
   81x PreToolUse:PowerShell  commit subject / PR title convention      avg 81.8s  max 146.5s
   73x Stop                   lane-stop gate                            avg 27.6s  max  66.8s
   68x PreToolUse:PowerShell  commit-message convention                 avg 78.0s  max 134.1s
   55x PreToolUse:PowerShell  dangerous git commands                    avg 75.9s  max 134.1s
   52x Stop                   silent destructive-guard failures         avg 31.8s  max  57.9s
   43x PreToolUse:PowerShell  --no-verify bypass                        avg 76.1s  max 134.1s
   27x PreToolUse:Bash        Windows drive-root /tmp writes            avg 73.4s  max 112.6s
   10x PostToolBatch          context-zone crossing                     avg 73.0s  max  96.0s

Note every duration is 2-8x past the 15 s timeout. The guard is killed mid-run and never renders a verdict - the user pays 15-160 s for a check that does not complete. These guards are currently pure cost with zero protective value on this platform.

Static call-site counts (indicative, not runtime)

External-command call sites per script (jq|grep|sed|awk|date|git|python|realpath|dirname|basename|cut|tr). Many sit in branches, so this is an upper bound, not an executed-spawn count:

 127  block-dangerous-git.sh
 113  hook-utils.sh
 110  block-noncanonical-commit.sh
  52  block-hook-bypass.sh
  38  stale-path-verify.sh
  30  block-no-verify.sh
  23  block-convention-violation.sh
  22  skill-reference-verify.sh
  22  cli-flag-verify.sh
  21  hardcoded-path-check.sh

hook-utils.sh is sourced by every guardrails hook, so its 113 call sites are paid on every hook run that reaches them.

Environment / what is NOT the cause

• Windows 11 Pro 26200, AzureAD-joined. Claude Code 2.1.251 (native install). Git Bash (MSYS).
• Defender is not the cause. WinDefend service is Stopped (StartType Manual); Get-MpPreference and Get-MpComputerStatus both fail with "Provider load failure".
• No AppLocker policy. AppInit_DLLs empty. Smart App Control off.
• Prime suspect: Win32_DeviceGuard reports CodeIntegrityPolicyEnforcementStatus = 2 (WDAC kernel-mode policy enforced) with VirtualizationBasedSecurityStatus = 2. A WDAC policy in enforcement mode validates code integrity on every process launch, which fits 300-900 ms spawns - especially for unsigned MSYS binaries that miss the signature cache.
• Not yet checked: fltmc filters requires elevation. Enumerating minifilter drivers is the remaining unknown.

Proposed work, in value order

1. Cut spawn COUNT, not script runtime. This is the whole game. Concretely:

• Collapse multi-jq call sites into a single jq invocation per hook (hook::jq_fields already does this in places - apply it everywhere).
• Replace grep/sed/cut/tr/basename/dirname subprocess calls with bash builtins (parameter expansion, [[ =~ ]]). Each one removed saves ~0.9 s on this class of host.
• Avoid sourcing the full hook-utils.sh when a hook needs two helpers.

2. Consolidate hooks per event. 17 PreToolUse commands is 17 shells. A single dispatcher process that runs the guards in-process and returns one verdict would cut PreToolUse cost by roughly 17x on the spawn axis alone.

3. Narrow matchers. Several guards fire on every Bash call but only care about git/gh invocations. A matcher that excludes non-git commands removes most of the fan-out for free.

4. Add a platform escape hatch. A documented switch to disable the shell-based guard set on Windows hosts where spawn cost is pathological, so the fleet degrades to "unprotected but usable" instead of "protected in theory, unusable in practice".

5. Raise or make configurable the 15 s hook timeout - secondary. Currently every one of these runs is killed, so the guard provides no protection while still costing the full wall-clock.

Out of scope for this repo

The 872 ms native process-creation cost is a machine/IT problem (likely the enforced WDAC policy). Worth pursuing in parallel with IT - a code-integrity exclusion for the toolchain would recover most of the 20.6 hours without any change here. This issue covers making the hook set resilient to slow hosts regardless.

Per-hook children

To be filed separately so a Windows host can work them independently:

• source-control: pr-issue-linkage gate (423 timeouts - highest single offender)
• source-control: git worktree nesting invariant (418)
• guardrails: block-convention-violation.sh commit subject / PR title (207 across Bash + PowerShell)
• guardrails: Stop - unsurfaced hook failures (113)
• guardrails: block-hook-bypass.sh perf (105) - correctness tracked separately in fix(guardrails): block-hook-bypass.sh fails CLOSED on a Windows stdin read stall, blocking valid tool calls with 'hook stdin is not valid JSON' #3507
• guardrails: block-noncanonical-commit.sh (91)
• autonomy: Stop - lane-stop gate (73)
• guardrails: block-dangerous-git.sh (59)
• guardrails: Stop - silent destructive-guard failures (52)
• guardrails: block-windows-drive-tmp.sh (49)
• guardrails: block-no-verify.sh (44)
• guardrails: block-exported-msys-pathconv.sh (15)
• context-guard: PostToolBatch context-zone crossing (10)
• guardrails: secret-pattern-detection.sh / hardcoded-path-check.sh (PreToolUse:Edit, ~60 s each observed)

Acceptance criteria

• Median PreToolUse hook-stack wall-clock on a Windows host is under 2 s.
• No hook in the set exceeds 5 external process spawns on its common path.
• A documented way to disable the shell-guard set per-platform exists.
• Re-measuring the transcript corpus after the change shows a >90% reduction in timedOut: true hook attachments.

Method

Counts derived from ~/.claude/projects/**/*.jsonl hook_cancelled attachment records (timedOut: true, durationMs, timeoutMs) across 236 sessions, 2026-08-23 to 2026-08-31. Spawn timings from time over 10 iterations each.

[kyle-sexton]

Per-hook children filed:

Issue	Plugin	Hook	Timeouts
#3509	source-control	pr-issue-linkage gate	423
#3510	source-control	git worktree add nesting invariant	418
#3511	guardrails	block-convention-violation.sh	207
#3512	guardrails	Stop: unsurfaced hook failures	113
#3513	guardrails	block-hook-bypass.sh (perf)	105
#3514	guardrails	block-noncanonical-commit.sh	91
#3515	autonomy	Stop: lane-stop gate	73
#3516	guardrails	Stop: silent destructive-guard failures	52
#3517	guardrails	block-windows-drive-tmp.sh	49
#3518	guardrails	block-no-verify.sh	44
#3519	guardrails	block-exported-msys-pathconv.sh	15
#3520	context-guard	PostToolBatch: context-zone crossing	10
#3521	guardrails	secret-pattern-detection.sh + hardcoded-path-check.sh	3

Not filed here: guardrails/block-dangerous-git.sh (59 timeouts, avg 75.9s, 127 external call sites) — already claimed by a separate in-flight session.

Related correctness issue: #3507 (block-hook-bypass.sh fails CLOSED on Windows stdin stall).

[kyle-sexton]

Correction on the suspected cause — WDAC is weaker evidence than the issue body implies.

The body names an enforced WDAC policy as the "prime suspect". My own measurement argues against it being the mechanism:

cmd.exe /c exit was spawned 10 times — the same binary each time — and every spawn cost ~872 ms flat. If per-process code-integrity validation were the cause, a signature cache should make spawns 2-10 substantially cheaper than spawn 1. Flat cost across identical repeated spawns points away from one-time-per-binary validation and toward something sitting in the per-creation path itself: a filesystem minifilter, an ETW consumer, or a process-creation callback.

CodeIntegrityPolicyEnforcementStatus = 2 is a real observation and worth reporting to IT, but it should not be presented as the identified cause.

Corrected status: root cause unidentified. What is established:

• Process creation costs 0.3-0.9 s per spawn on this host, ~150-200x a healthy baseline.
• It is not MSYS/Git-Bash specific (native cmd.exe is equally slow).
• It is not Windows Defender (WinDefend is Stopped; the WMI provider fails to load).
• It is not AppLocker, AppInit_DLLs, or Smart App Control (all absent/off).

Discriminating next test: fltmc filters under elevation, to enumerate minifilter drivers. That was not possible in the diagnosing session (access denied without admin).

None of this changes the remediation. The 1,778 timeouts / 20.6 hours are measured, and reducing process-spawn count per hook is the correct fix on any host where spawn cost is high — whatever is ultimately making it high here.

[kyle-sexton]

Second correction: the diagnosis is CONTENTION, not WDAC. Measured by /claude-ops:audit-performance.

I re-ran this through the purpose-built engine (claude-ops:audit-performance, which takes a load-labelled no-op spawn baseline). It reaches a better-supported verdict than the hand-rolled numbers in the issue body, and it invalidates the framing of my first correction as well.

Spawn cost is BIMODAL, not a flat floor

"spawn_cost": {
  "samples": 7,
  "concurrent_processes_at_sample": 501,
  "findings": ["bimodal-spawn-latency"],
  "min_ms": 180.5,
  "median_ms": 1107.7,
  "max_ms": 2841.3,
  "spread_ratio": 15.74,
  "command": "cmd /c exit"
}

A 15.7x spread across identical no-op spawns, sampled at 501 concurrent processes on the machine. Per the engine's own reading guidance, bimodal-spawn-latency is the contention diagnosis rather than a hint toward one. min_ms of 180 ms shows the machine is capable of far better when uncontended.

This corroborates independent measurement from a parallel session working the disk-hygiene guard, which saw bare bash -c true at 1825 ms and 283 ms within the same hour at ~10% CPU — roughly 6x drift.

Consequences for this issue, and they are significant:

1. The single-number spawn cost in the issue body (661/872/908 ms) is a sample under load, not a property of the machine. It should not be quoted without concurrent_processes_at_sample.
2. Durations are not comparable across time on this host. The per-hook averages in the table above, and the rankings derived from them, are unreliable relative to each other. The 20.6-hour aggregate stands; the head-to-head ordering does not.
3. Every child issue should lead with a SPAWN COUNT, not a duration. A spawn count is deterministic, survives this drift, and is cheap for a reviewer to verify. Recommended method: a PATH shim directory of wrapper scripts that log their own name then exec the real tool, diffed before and after.
4. WDAC remains present (CodeIntegrityPolicyEnforcementStatus = 2) but is now the weaker of two explanations. Note also that WinDefend being Stopped with a provider load failure is consistent with a third-party EDR having displaced Defender, not with no scanner running — so scanning is not ruled out, and WDAC and a filter driver are not mutually exclusive. fltmc filters under elevation is still the discriminating test.

New evidence the issue body did not have

Per-turn hooks — the bucket nobody looks at. The engine separates them:

total hooks: 62   (enabled plugins: 69, plugins contributing hooks: 22)
per_tool_call: 39     <- scales with tool-call volume
per_turn:       7     <- scales with conversation length
other:         16

39 hooks fire per tool call. The 7 per-turn hooks (autonomy, claude-ops, codex, context-guard, disk-hygiene, security-guidance) are what make a long conversation degrade, and none of the children above cover that axis.

Subagent fan-out multiplies all of it.

"CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH": { "value": "5", "documented_default": 3, "above_documented_default": true },
"CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS":  { "value": "12", "documented_default": 20 }

Depth 5 (above the documented default of 3) against 12 concurrent subagents per session, with every subagent carrying the same 39-hook per-tool-call fan-out as its parent. Seven sessions were active in the last hour. That is the mechanism by which a modest-looking configuration licenses a very large process population.

(Trap worth recording: these are read through a truthiness test on the raw string, and "0" is truthy. Setting one to 0 is a silent no-op; only removing the variable disables it.)

Statusline is an additional bash spawn on a 60 s refresh: bash "C:/Users/KyleSexton/.claude/statusline/entrypoint.sh".

Cleared by measurement (recording the negatives, so nobody re-derives them):

• Install-tree state: sweep_health.findings: [], tree_census.walk_seconds: 2.858. Healthy.
• Version regression: 2.1.251, current on the latest channel. slow_version_probe: false, probe took 0.086 s.
• Claude Code is not the process population: of 501 processes, only 5 claude.exe and 2 node/bun. The contention is coming from elsewhere on the machine.

Reusable optimization pattern, from a completed fix

A parallel session took the disk-hygiene guard launcher from 4 process spawns per warm invocation to 1 and measured it with an interleaved A/B (24 pairs, arms alternating within one run so the drift hits both equally):

BEFORE  p50 = 5446 ms   p95 = 16991 ms
AFTER   p50 = 1418 ms   p95 =  7874 ms     median paired ratio 3.71x
AFTER   min =  124 ms

The AFTER min = 124 ms is the important line: with spawn count minimised, the hook lands in ~124 ms when the machine is briefly uncontended. The remaining wall-clock is almost entirely the one irreducible interpreter spawn.

The 3 spawns removed were: dirname, a sed read of a 3,500-line file, and a whole extra Python interpreter launched only to evaluate a sys.version_info >= MIN_PYTHON predicate. None of that work was slow in itself — it was 3 process creations.

Three non-obvious traps, all of which cost that session a round and none of which are visible in the script text:

1. x="$(f)" is a spawn. Command substitution forks a subshell, and on MSYS a subshell is a real process creation. A "builtins-only" helper that returns its answer on stdout still costs a full process. Hot-path helpers must assign to a global instead. This likely invalidates "already builtins" assumptions across several of the children.
2. ${var: -N} returns the EMPTY string when the string is shorter than N. It silently collapsed a per-plugin cache key into one shared file.
3. os._exit / hard exits skip stdio flushing. A hook that buffers its decision and then hard-exits loses the decision, and the harness sees no output — which for a PreToolUse gate is a fail-OPEN. That is a correctness bug, not a perf one, and worth checking in any hook that exits non-cooperatively.

Caching pattern that produced the 4->1: cache the expensive resolution rather than making it fast. Key on $PATH verbatim plus the resolved binary's identity; validate with [[ -x ]], [[ -s ]] and [[ ! "$bin" -nt "$cachefile" ]] (all builtin, and -nt catches an in-place upgrade); add a TTL; publish with temp-file + mv -f for concurrent writers; and make every miss fall back to full resolution, never to "no result".

Acceptance criterion correction

"A single run completes in under 2 s on a Windows host" is barely compatible with "no more than 2 external process spawns" — at 0.66-0.91 s per spawn, 2 spawns is already 1.3-1.8 s before any work, and under contention it is far worse. Restate as: "under 2 s at a measured spawn cost of X ms, with X reported alongside." Otherwise a pass on a healthy box becomes a fail on a contended one and the criterion loses meaning. The spawn-count criterion is the one that should gate review.

This tax causes INCORRECT DENIALS, not just slow ones

Reframing the severity. The disk-hygiene guard's watchdog fired twice in a parallel session and denied two ordinary read-only grep commands with internal deadline of 10s exceeded. Both succeeded on identical retry.

That is the important consequence and the issue body understates it: a timing-derived guard failure is not merely latency, it is a non-deterministic false denial of legitimate work. Combined with the fail-closed stdin path in #3507, the pattern is that this hook set converts host contention into arbitrary, unreproducible blocks. A guard that denies correct commands under load is worse than no guard, because the operator cannot distinguish it from a real policy decision.

Related, filed separately

• disk-hygiene: _engine_gate_relevant samefile-scans every token of every command, not just separator-carrying words as documented #3527 — disk-hygiene: _engine_gate_relevant samefile-scans every token of every command rather than only separator-carrying words, contradicting both its docstring and its inline comment. A dead drive letter or disconnected UNC path in an unrelated command blocks for as long as the OS takes to fail. A concrete instance of "the work inside a spawn can also be unbounded" — spawn count remains the dominant term, but not the only one.
• guardrails: hooks exit 1 with no diagnostic when they abort, so a blocking guard silently enforces nothing #3528 — guardrails: hooks exit 1 with no diagnostic when they abort. Flagged in the wild for cli-flag-verify.sh and block-windows-drive-tmp.sh, neither of which contains an explicit exit 1 and neither of which uses set -e. Not reproducible on demand, so filed as a robustness gap: there is no ERR/EXIT trap, so any abort between source hook-utils.sh and the final exit 0 exits silently — and for a PreToolUse guard, exit 1 is non-blocking, so it enforced nothing and told nobody. The process-creation tax documented here is the plausible trigger.

The suggested fix for #3528 is a shared trap helper in hook-utils.sh rather than per-hook edits, since one change covers all 17 PreToolUse and 22 PostToolUse registrations. If hook-utils.sh is being touched for the spawn reductions anyway, both should land together.

[kyle-sexton]

Child list amendments:

• perf(guardrails): block-dangerous-git.sh has 127 external-command call sites, the most in the set - reduce process spawns #3529 filed — guardrails/block-dangerous-git.sh (127 call sites, the most in the set). It was originally left unfiled on a mistaken assumption that a parallel session owned it; that session has confirmed it does not. Now owned.
• perf(disk-hygiene): Stop-event guard_launch_monitor times out 52x via run-python-hook.sh launcher overhead #3516 retitled to disk-hygiene — it was misattributed to guardrails on filing. It is disk-hygiene/skills/clean/scripts/guard_launch_monitor.py via hooks/run-python-hook.sh, and a fix is already in flight on perf/disk-hygiene-guard-hook-spawns.
• disk-hygiene: _engine_gate_relevant samefile-scans every token of every command, not just separator-carrying words as documented #3527 and guardrails: hooks exit 1 with no diagnostic when they abort, so a blocking guard silently enforces nothing #3528 filed independently against disk-hygiene and guardrails respectively; both are cross-referenced in the correction comment above.

Full child set is now #3509-#3521, #3529, plus #3527/#3528, with #3507 tracking the fail-closed correctness bug.

[kyle-sexton]

Finding from shard #3520 that changes the diagnosis for the remaining shards

Posted by the autonomous worker lane (vm-worker-202609050257) after landing draft PR #3779 for #3520. Recording it here because it affects how the other twelve shards should be approached, not just this one.

The stated cause was not the cause here

This campaign attributes the tax to per-field jq forks. In zone-crossing-inject.sh that was already fixed — the hook batched both envelope fields into a single jq. The real cost was redirection placement.

Bash elides the extra fork inside $(...) and execs in the substitution's own subshell only when the command carries no redirection of its own. A 2>/dev/null, a <<<, or a pipeline written inside the substitution defeats that optimization and forks twice for one program. Measured on this host:

form	processes
$(jq . f)	1
$(jq . f 2>/dev/null)	2
$(printf … | jq …)	3
{ V=$(jq . f); } 2>/dev/null	1

Hoisting the redirects onto enclosing groups took this hook from 8 process creations to 3, with execve unchanged at 4 — same programs, same inputs. That invariance is the evidence it is a latency fix rather than work removed.

The existing budget test was measuring the wrong thing

This is the part worth propagating. The plugin's xtrace-based budget test read "2 processes" while the kernel was making 8, and passed. A fork that never execs never reaches a command position, so an xtrace command-position count is blind to exactly the fork this campaign is about.

Any shard validated against a command-position budget may be reporting a saving it did not make, or missing a cost it still has. The replacement in #3779 pins creations by strace -f -e trace=clone,clone3,fork,vfork,execve at exactly 3 and launches at exactly 4, and was verified non-vacuous by mutation: moving one redirect back inside its substitution takes the count to 4 and fails the test, while the old command-position budget passed silently on the same mutation.

Recommendation for the remaining shards: check redirection placement before assuming jq batching is the fix, and measure with a trace-based creation count rather than a command-position count.

One saving deliberately declined

A further process was available by handing stdin straight to jq instead of keeping the payload.sh drain loop. That was not taken: the loop carries a documented bounded read -t 5 that caps a stalled pipe, which is the exact timeout symptom this campaign exists to fix. Trading it for one fork would have reintroduced the failure mode.

Not yet confirmed on the target platform

Wall-clock is not measurable on this Linux runner (~1 ms/spawn) against the Windows tax this campaign documents (180-2,841 ms/spawn, median 1,108 ms). At that median, 5 fewer creations is roughly 5.5 s per fire, but that projection needs confirming on a real Windows host before the acceptance criterion is signed off. No timing figure was invented.

---

Generated by Claude Code

[kyle-sexton]

Campaign-wide finding: no test guards the dimension this campaign is about

Posted by the autonomous worker lane (vm-worker-202609050257) after a measured verification pass over #3513, #3514, #3517, #3518 and #3519. Recording here because two of these affect every shard.

1. The guardrails budget test pins execve only, not forks

run-guards.test.sh:168-215 counts with PATH shims and asserts on execve. The fork dimension is unguarded. That is the same blind spot #3779 found in the xtrace command-position budget, which read 2 while the kernel made 8: a fork that never execs is invisible to both methods.

Since this campaign is about process creations, not program launches, every shard validated against either method may be reporting a saving it did not make or missing a cost it still has. A strace -f -e trace=clone,clone3,fork,vfork,execve budget is the only method that has held up.

2. Credit for the recent wins is misattributed

The measured record across the eight-guard Bash matcher, benign call: 16 execve / 65 creations before #3781, now 3 execve / 36 creations, with batch p50 going 97 → 78 → 67 → 49 ms across #3781, #3788 and #3820.

But per-shard, #3788 is repeatedly credited for work it did not do:

• perf(guardrails): block-noncanonical-commit.sh averages 78.0s and timed out 91x - reduce process spawns #3514 — perf(hooks): cut leftover Bash parse and dirname tax on the hot path #3788 changed its exec and fork counts by exactly zero. Its win there was deferring the 41 KB ps-command.sh parse (78→67 ms). The 2 git execs and 5 forks were removed by 273c20fe (perf(guardrails): drop leftover git probes on a benign Bash call #3820).
• perf(guardrails): block-no-verify.sh averages 76.1s and timed out 44x - reduce process spawns #3518 — perf(guardrails): drop dirname and sed execs from the always-on path #3781 removed its dirname; perf(hooks): cut leftover Bash parse and dirname tax on the hot path #3788 moved a $(cd … && pwd) that never forks, because Claude Code always sets CLAUDE_PLUGIN_ROOT.
• perf(guardrails): block-windows-drive-tmp.sh averages 73.4s and timed out 49x - reduce process spawns #3517 and perf(guardrails): block-exported-msys-pathconv.sh averages 87.5s and timed out 15x - reduce process spawns #3519 — both fixed by perf(guardrails): drop dirname and sed execs from the always-on path #3781, not perf(hooks): cut leftover Bash parse and dirname tax on the hot path #3788.

Anyone sizing remaining work off "#3788 fixed it" should re-derive.

Per-shard verdicts, measured

#	verdict	measured	note
#3513	PARTLY FIXED	0 execve, 7 creations — largest in the plugin	5 of 7 are in-file: :159 unconditional file-scope SUBJECT=$(…), :478 $(strip_literals), and four done < <(printf …) process substitutions. Keep open.
#3514	PARTLY FIXED	0 execve, 3 creations	Close, re-file the residual
#3517	FULLY FIXED	0 execve; 0 forks on Linux/macOS (its OSTYPE gate precedes buffer_stdin), 2 on the msys Bash lane	Close
#3518	PARTLY FIXED	0 execve, 3 creations	Close, re-file the residual
#3519	FULLY FIXED	0 execve, 1 creation	Close

3. The largest remaining fleet win is in the fenced file

Of the 36 creations in a benign eight-guard batch, 8 come from the absence of a hook::buffer_stdin_to <var> form in lib/hook-utils.sh. That is one change in one shared file worth more than several remaining shards combined — but it is the file unmerged PRs #3740 and #3838 own, so no shard can take it.

The in-process batching claim does hold up: run-guards.sh calls hook::buffer_stdin once and primes jq once for the whole batch, so no individual guard contributes a jq spawn.

---

Generated by Claude Code

[kyle-sexton]

This was generated by AI during triage.

Cross-reference: #3623 is the program created to solve this, and it has landed

This issue is the original problem statement. #3623 ("Hook performance program: measure and cut every runtime-cost surface on the Windows host") is the execution vehicle that was opened against it, and as of 2026-09-03 every one of its eight phases is checked with Phase 8 merged as #3679.

The mapping onto this issue's own proposed-work list is direct:

This issue proposed	#3623 phase
Cut spawn count, not script runtime	Phases 4a / 4b / 4c (guard, telemetry envelope, Write formatter hot paths)
Consolidate hooks per event	Phase 3 plus the guardrails dispatcher, #3621
Narrow matchers	Phase 3 (if gates, matcher scoping, explicit timeouts)
Raise or make configurable the timeout	Phase 3 (explicit timeouts)
Platform escape hatch	Not taken

#3623's outcome comment carries the after-column measured on the same host class: PostToolUse:Write 13,225 to 1,949 ms, PostToolUse:Edit 17,192 to 3,048 ms, PostToolBatch 1,254 to 282 ms, UserPromptSubmit 975 to 297 ms, PreToolUse:Bash 2,475 to 1,599 ms.

What is still open here, and why this should not be closed on that basis:

1. The per-tool-call surfaces still miss the hook-budget ceiling. 1.4 to 1.9 s against the 1 s typical ceiling on benign samples, 2.1 to 3.3 s on Edit and substitution samples. Hook performance program: measure and cut every runtime-cost surface on the Windows host #3623 assigns the whole of that residual to the guardrails dispatcher, now tracked as guardrails dispatcher is the whole per-tool-call budget miss after the hook-performance program #3685.
2. This issue's fourth acceptance criterion is unverified. Re-measuring the transcript corpus for a >90% reduction in timedOut: true attachments was the criterion that closes the loop from the 1,778-timeout evidence, and no such re-measurement appears in either thread. That is the open work item here, and it is now a measurement task rather than a planning one.
3. The platform escape hatch was never taken. No phase covers it.
4. The per-hook children checklist in the body should be reconciled against what actually landed, rather than assumed closed by the program.

Recommendation: link #3623 as the executing program and re-scope this issue to the re-measurement plus the two untaken items, rather than closing or consolidating. A human should decide whether the residual justifies keeping priority: critical. Nothing was closed, relabeled, or edited by this pass.

Also cross-linked: #3505 (skill-listing aggregate) shares the hook-budget and context-budget territory but is a distinct surface; #3623's Phase 6 touched it and left it substantially open.

---

Generated by Claude Code