perf(hook-utils): cut three subprocess spawns per hook invocation

[kyle-sexton]

Closes #1978

Summary

Every hook in this marketplace sources lib/hook-utils.sh, and buffering the hook payload spawned
three external processes to do work bash can do in-process. On Windows Git Bash, where process
creation is fork() emulation, each spawn costs roughly 140 ms — paid on every tool call, in all 16
plugins that carry the library.

Fix

• hook::resolve_read_slice: the awk float division becomes fixed-point shell arithmetic,
  printing the same three-decimal form read -t is given. printf -v, not $( ), because a command
  substitution forks the shell even for a builtin — the fork is the cost being removed.
• hook::buffer_stdin: printf | tr -d '\r' becomes ${input//$'\r'/}, and the post-loop
  jq -e . validity probe is skipped when hook::json_complete already parsed the identical
  CR-stripped buffer with jq inside the read loop. json_complete returns non-zero both for an
  incomplete buffer and for absent/broken jq, so the flag is set only on its success path and the
  jq-absent fail-open is untouched.
• New hook::jq_fields: extracts several fields from one payload in a single jq process, for
  hooks that read two or three fields from the same envelope and currently pay a fork plus an exec
  for each. It uses // "" rather than // empty so an absent field keeps its slot instead of
  silently shifting every later index onto the wrong filter, reads NUL-separated values through a
  process substitution (command substitution strips NUL), and strips CR after the read — the
  Windows jq build writes stdout in text mode and expands every LF it emits to CRLF, so a value
  cleaned inside jq arrives dirty anyway.

No hook call sites change in this PR. The plugins that read a second field already gate it behind an
early exit or a telemetry probe, so converting them would add work on the common path; the batch
helper's win is in the guardrails git guards, which read .tool_input.command and .tool_name
unconditionally — and those files are in flight in #1974. The helper ships now because the lib sync
gate makes every library change cost a version bump in all 16 carrying plugins; adding it later would
pay that a second time.

Verification

Measured, quiet box, 15 alternating pairs of the same block-dangerous-git invocation against
each library version (alternating so machine-load drift hits both arms equally):

lib	mean	min	max
main	1672 ms	1316 ms	2443 ms
this branch	1401 ms	1120 ms	1760 ms

~270 ms per invocation, and the slow tail shrinks with the mean. That is less than the
3 × 140 ms the spawn-count model predicts; the measured number is the one to trust.

Gates run locally:

• lib/hook-utils.test.sh — new coverage for the slice format (including the fallbacks a
  non-numeric bound and a 0.000 quotient must take) and for hook::jq_fields (multi-line and
  CR-carrying values, absent-field slot retention, unparsable payload, no-filter call,
  non-string values). The two buffer_stdin timing assertions that fail intermittently here fail
  the same way on main (1–3 failures per run on both sides) — they are wall-clock-ceiling tests
  on a loaded Windows box, the same class as the ceilings tracked for
  block-noncanonical-commit.test.sh.
• plugins/guardrails/hooks/block-dangerous-git.test.sh — the black-box hook contract suite, run
  serially (never concurrently: its wall-clock assertions fail spuriously under parallelism).
• scripts/sync-hook-utils.sh --check — all 16 plugin copies match.
• scripts/sync-hook-utils.sh --check-bump origin/main — every carrying plugin bumped.
• scripts/check-changelog-parity.sh --check-bump origin/main and --check-order.
• scripts/check-shell-portability.sh --paths, shellcheck -x, shfmt -d -i 2,
  markdownlint-cli2, scripts/check-manifest-duplicate-keys.py.

Fresh-docs mandate: no WebFetch was required for this change and none was performed. The edit is
internal implementation of a shell library — it touches no hook contract surface, no manifest field
beyond the mechanical version bumps the sync gate itself demands, and no documented harness
behavior. The 16 touched manifests are version lines only.

Related

• Refs fix(guardrails): stop blocking a PowerShell call of a constant target #1974 — carries the guardrails PowerShell false-positive fix and touches
  plugins/guardrails/CHANGELOG.md and plugin.json. Both PRs bump guardrails to 0.19.1, so
  whichever merges second needs a one-line rebase onto 0.19.2.
• Refs ci: verify the shared hook lib on Windows #1975 — adds the Windows CI job for lib/hook-utils.test.sh; it is the coverage that would
  have caught a Windows-only regression in this file.

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[claude]

Claude finished @kyle-sexton's task in 5m 53s —— View job

---

Review of PR #1979 — perf(hook-utils): cut three subprocess spawns per hook invocation

• Gather context (PR body, custom instructions, CLAUDE.md)
• Fetch diff via git diff origin/main...HEAD
• Review lib/hook-utils.sh core changes (resolve_read_slice, buffer_stdin, new jq_fields)
• Review lib/hook-utils.test.sh coverage
• Verify parity across the 15 plugin mirror copies + manifest/changelog bumps
• Post final review

Summary

Solid, well-verified change. I traced the resolve_read_slice fixed-point arithmetic by hand against the old awk "%.3f", t/n output for every case in the new test table (t=2→0.500, t=10→2.500, t=0.5→0.125, t=0.004→0.001, t=0.000→0.000 1 fallback, non-numeric→fallback) — all match, including the documented half-millisecond rounding seam vs. awk. I also confirmed all 15 plugins/*/hooks/hook-utils.sh copies are byte-identical to lib/hook-utils.sh, every carrying plugin's plugin.json took a correct patch bump, and the CHANGELOG entries are consistent across the sampled plugins (guardrails, rate-limit-guard, typos-format). The hook::buffer_stdin reuse of the json_complete verdict via the new validated flag is correct: the string checked and the string later assigned to input after CR-stripping are byte-identical, since no more input is read between the check and the reassignment.

Finding

hook::jq_fields silently collapses a literal false field to the same empty-string sentinel as an absent/null field, contradicting its own doc comment.

lib/hook-utils.sh#L651:

prog+="((${filter}) // \"\" | tostring)"

jq's // alternative operator treats false as falsy exactly like null — not just "absent/error." Verified directly:

$ echo '{"a":false,"b":true}' | jq -c '{a: ((.a) // "" | tostring), b: ((.b) // "" | tostring)}'
{"a":"","b":"true"}

The function's own doc comment (lines ~620-624) says: "An absent, null, or empty field becomes the EMPTY STRING and keeps its slot... Emptiness stays the caller's decision." A literal false isn't absent, null, or empty — but it's silently indistinguishable from an absent field under the current expression. This is the same pre-existing quirk in hook::jq_field (which uses // empty), but it's worth catching here because hook::jq_fields's whole design rationale (// "" instead of // empty) is specifically about not letting a field's value get lossily conflated with absence — and this one case still does.

Impact today is latent: the PR explicitly notes no call sites use this helper yet, and the current candidate future callers (.tool_input.command, .tool_name) are string fields. But it's new, heavily-documented library surface that future hooks (e.g. a boolean flag like a success/enabled field) will build on without knowing about this gap, and the test suite covers null/number/absent but not a false value.

Suggested fix: replace the alternative-operator form with an explicit null check, e.g. ((${filter}) as $v | if $v == null then "" else ($v | tostring) end), and add a test case with a false-valued field.

Fix this →

Everything else

• No architectural concerns — shipping hook::jq_fields now without call sites is explicitly justified by the sync-gate's per-version-bump cost, and that reasoning holds.
• Fresh-docs mandate self-assessment (no WebFetch needed) is correct: this touches no hook contract surface, and the 16 manifest diffs are mechanical version-only bumps.
• hook::buffer_stdin's switch from printf | tr -d '\r' to ${input//$'\r'/} and the read_slice awk removal are behavior-preserving and correctly reasoned.

[claude]

Claude finished @kyle-sexton's task in 2m 11s —— View job

---

Security review

• Gather context (gh pr diff, read changed files)
• Review lib/hook-utils.sh changes for injection / logic flaws
• Review lib/hook-utils.test.sh for issues
• Review the 16 plugin-synced copies + manifest/changelog bumps
• Post findings

Scope reviewed: lib/hook-utils.sh (source of truth), lib/hook-utils.test.sh, and the 16 synced plugins/*/hooks/hook-utils.sh copies + their plugin.json/CHANGELOG.md version bumps. No workflow files are touched by this PR.

No security issues found. This is a narrowly-scoped internal perf refactor with no new external inputs, no privilege changes, and no injection surfaces introduced. Specifics I checked and ruled out:

• Bash-arithmetic injection in hook::resolve_read_slice (lib/hook-utils.sh#L463-L498): $t (from the stdin_read_timeout userConfig, CLAUDE_PLUGIN_OPTION_STDIN_READ_TIMEOUT) is only used inside a [[ ... =~ ^([0-9]+)(\.([0-9]+))?$ ]] match. The $((...)) arithmetic that follows uses only ${BASH_REMATCH[1]}/${BASH_REMATCH[3]} — values the anchored, digits-only regex guarantees contain nothing but 0-9. Bash arithmetic recursively expands variable references, which is a classic injection vector when the raw attacker-influenced string reaches $(( )) directly, but that never happens here — only the pre-validated digit-only captures do. Overflow/garbage inputs fall through to the documented unsliced "<t> 1" form rather than misbehaving.
• hook::buffer_stdin's new validated short-circuit (lib/hook-utils.sh#L500-L596): this is the security-relevant path, since guard hooks like block-dangerous-git rely on hook::buffer_stdin's validity verdict before parsing .tool_input.command. Traced it end-to-end: validated=1 is only set immediately before a break, so no further mutation of input can occur between the hook::json_complete check and the final ((validated == 0)) && ... gate — the post-loop input="${input//$'\r'/}" re-strip is idempotent on an already CR-stripped string. The skip reuses a verdict jq already produced on the exact same bytes; it doesn't weaken the fail-open behavior for a jq-absent host (untouched code path) or let malformed JSON through.
• New hook::jq_fields (lib/hook-utils.sh#L614-L677): the untrusted hook payload is passed to jq as stdin data (printf '%s' "$input" | jq -j "$prog"), never interpolated into the jq program string — the filters concatenated into $prog are literal strings supplied by call sites, not derived from the payload, so there's no jq-filter-injection path. Confirmed via grep that no hook in this PR calls hook::jq_fields yet (it ships unused, per the PR description, for a future PR) — so there's no live call site to assess for a tainted-filter misuse today. Worth keeping in mind for whichever PR wires up the first caller: hook::jq_fields must only ever be called with static, hardcoded jq filter strings, never a filter built from hook input — but that's a note for future review, not a finding against this PR.
• NUL-separated field parsing: read via process substitution (not $( ), which strips NULs) with a ((${#values[@]} == $#)) || return 1 count check — an embedded literal `` inside a JSON string value (the one documented residual) would desync the count and fail closed rather than silently return misaligned/wrong field values.
• Manifest / changelog changes: all 16 plugin.json diffs are version-line-only bumps (no permissions, no new commands/MCP servers, no config surface changes); all 16 hooks/hook-utils.sh copies are byte-identical to the lib/hook-utils.sh source (matching SHAs), consistent with the sync-gate guarantee. No secrets or credentials present in the CHANGELOG additions I spot-checked.

No CRITICAL, IMPORTANT, or SUGGESTION findings to report.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5fae68cf1d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[github-actions]

Claude has reviewed this PR 3 times. The lane skips further automatic reviews after 5; deleting this comment resets the count.

[claude]

Claude finished @kyle-sexton's task in 2m 36s —— View job

---

Review of PR #1979 — perf(hook-utils): cut three subprocess spawns per hook invocation (re-run on synchronize)

• Gather context (PR body, CLAUDE.md, prior review comments)
• Diff origin/main...HEAD to see what changed since the last review pass
• Confirm lib/hook-utils.sh content is unchanged since commit 5fae68c (the merge commit only reconciles plugins/source-control/.claude-plugin/plugin.json)
• Re-check the previously-flagged hook::jq_fields finding and Codex's new nounset comment
• Post updated review

What changed since the last review

Nothing in lib/hook-utils.sh or lib/hook-utils.test.sh. git diff 5fae68c..HEAD -- lib/hook-utils.sh is empty — the second commit (fedcde6) is a merge of origin/main that only pulls in an unrelated plugins/source-control version bump. The correctness/test-coverage finding from my earlier pass is therefore still open:

hook::jq_fields still collapses a literal false field to the same empty-string sentinel as an absent field, at lib/hook-utils.sh#L651:

prog+="((${filter}) // \"\" | tostring)"

This contradicts the function's own doc comment (L620-623), which promises only an absent, null, or empty field becomes "". jq's // treats false as falsy too, so a real false value is indistinguishable from an absent field. Test coverage in lib/hook-utils.test.sh#L1598-L1602 exercises number and null but still has no false case. Not a regression risk today (no call sites exist yet, per the PR description), but it's new library surface a future boolean-field caller would build on without knowing about the gap.

Fix this →

On Codex's nounset comment (lib/hook-utils.sh#L675)

I looked into this and believe it's a false positive. The pre-4.4 Bash nounset bug is specific to expanding array elements — "${arr[@]}"/"${arr[*]}" on a zero-element array raises "unbound variable" under set -u. It does not apply to ${#arr[@]}, the length expansion, which is well-defined as 0 for an empty or unset array at any Bash version, including 3.2. The repo's own documented workaround in plugins/markdown-format/hooks/markdown-format.sh:444-447 makes exactly this distinction — it guards "${arr[@]}" expansions but leaves ${#arr[@]} checks on possibly-empty arrays unguarded throughout that same file (e.g. lines 527, 661, 684: while ((${#queue[@]} > 0)), if ((${#MODULE_FILES[@]} > 0)), if ((${#RISK_CONFIGS[@]} > 0))). If ${#arr[@]} itself aborted under set -u on empty arrays, those pre-existing unguarded call sites would already be broken on the same Bash range this comment worries about. hook::jq_fields's own test cases at lines 1582 and 1590 (unparsable payload, no-filter call) already exercise the values array staying empty and reaching line 675 under this test file's own set -uo pipefail (line 7) without failing, consistent with that reading. I'd treat this as no action needed, but flagging so the author can weigh in if there's a specific 3.2-4.3 Windows/macOS host that showed the abort in practice.

Everything else

• No other changes since my prior pass: hook::resolve_read_slice's fixed-point arithmetic, the printf -v (not $( )) discipline, and hook::buffer_stdin's validated-flag reuse of the json_complete verdict all check out as before.
• All 15 plugin-synced hook-utils.sh copies remain byte-identical to lib/hook-utils.sh; the only file touched by the merge commit outside lib/ and plugins/source-control is the version-bump reconciliation already covered by scripts/sync-hook-utils.sh --check-bump.
• Architecture, error-handling, and test-coverage decisions (shipping hook::jq_fields ahead of call sites, the NUL-separated wire format, the CR-stripped-after-jq ordering) remain well-justified and unchanged from the version already reviewed.
  ·

[claude]

Claude finished @kyle-sexton's task in 3m 37s —— View job

---

Security review of PR #1979

• Gather context (gh pr diff, read changed files)
• Review lib/hook-utils.sh changes for injection / logic flaws
• Review lib/hook-utils.test.sh for issues
• Review the 16 plugin-synced copies + manifest/changelog bumps
• Post findings

Scope reviewed: lib/hook-utils.sh (source of truth), lib/hook-utils.test.sh, and the 16 synced plugins/*/hooks/hook-utils.sh copies + their plugin.json/CHANGELOG.md version bumps. No workflow files are touched by this PR.

No new security-relevant changes since the last full review pass. I diffed the current head (fedcde6) against the commit already reviewed in depth (5fae68c): lib/hook-utils.sh and lib/hook-utils.test.sh are byte-identical between the two — the only new commit is a merge of origin/main, which touches none of the security-scoped files. The prior review's findings stand:

• hook::resolve_read_slice (lib/hook-utils.sh#L463-L498): the timeout value only ever reaches $(( )) through ${BASH_REMATCH[1]}/${BASH_REMATCH[3]}, captured by an anchored digits-only regex — no path for the raw, less-trusted string to reach shell arithmetic directly. No injection.
• hook::buffer_stdin's reuse of the hook::json_complete verdict via the new validated flag (lib/hook-utils.sh#L500-L596): validated=1 is set only immediately before the break that ends the loop on the exact same CR-stripped bytes checked; nothing mutates input in between. Guard hooks that gate on this function's validity verdict (e.g. block-dangerous-git) are unaffected — fail-open behavior for a jq-absent host is untouched.
• New hook::jq_fields (lib/hook-utils.sh#L614-L677): the untrusted hook payload is passed to jq as stdin data, never spliced into the jq program string — filters concatenated into prog are static strings from call sites, not payload-derived. Confirmed again: no hook in the repo calls hook::jq_fields yet, so there is no live call site with an injection surface today.
• NUL-separated field parsing: read via process substitution (not $( ), which would strip NULs), with a count check that fails closed (not mistaking a partial read for a complete one) rather than silently returning misaligned field values.
• All 16 plugins/*/hooks/hook-utils.sh copies remain byte-identical to lib/hook-utils.sh (matching SHAs in the diff), consistent with the sync-gate guarantee — no drifted copy could diverge in security-relevant behavior.

One non-security note for the author to double check, not a finding: plugins/source-control/.claude-plugin/plugin.json shows the worktree_create_gate_enabled userConfig property removed in this PR's diff, which looks like a merge-artifact from pulling in origin/main (worktree_root/worktree_create_gate_enabled land as part of an unrelated PR, #1970) rather than anything this PR intends. It isn't a security issue either way — worktree-create-gate.sh reads the flag as ${CLAUDE_PLUGIN_OPTION_WORKTREE_CREATE_GATE_ENABLED:-true}, so the gate stays fail-safe enabled even without the manifest declaring the option — but it's worth confirming the merge didn't silently drop a config surface that belongs on main.

No CRITICAL, IMPORTANT, or SUGGESTION security findings to report.

[claude]

Claude finished @kyle-sexton's task in 1m 50s —— View job

---

Review of PR #1979 — perf(hook-utils): cut three subprocess spawns per hook invocation (re-run on synchronize, HEAD 6ba4eb9)

• Gather context (PR body, CLAUDE.md, prior review comments)
• Diff origin/main...HEAD and fedcde6..6ba4eb9 to see what changed since the last full review pass
• Confirm lib/hook-utils.sh / lib/hook-utils.test.sh content is unchanged since the last review (the two new commits are merges of origin/main)
• Audit the merge commits for unintended drift in the files they touch
• Post updated review

What changed since the last review

lib/hook-utils.sh and lib/hook-utils.test.sh are byte-identical between fedcde6 (last reviewed) and 6ba4eb9 (current HEAD) — the two new commits are merges of origin/main (#1981, session-flow) with no direct edits to this PR's own source files. The previously-reported finding is therefore still open:

hook::jq_fields still collapses a literal false field to the same empty-string sentinel as an absent field, at lib/hook-utils.sh#L651 (prog+="((${filter}) // \"\" | tostring)"). jq's // treats false as falsy the same as null, contradicting the function's own doc comment at L620-623 ("An absent, null, or empty field becomes the EMPTY STRING"). Test coverage still has no false-valued case. Not a regression risk today (no call sites exist yet), but it's new library surface a future boolean-field caller will build on without knowing about the gap.

The Codex nounset comment on L675 remains resolved as a false positive per the author's own reply — ${#values[@]} is the nounset-safe length form, the repo already relies on that exact distinction elsewhere (markdown-format.sh), and the array is non-empty by construction at that point since hook::jq_fields returns early on $# == 0. Agreed, no action needed.

New finding (code-review lane): merge dropped a userConfig property that origin/main added and this plugin's own hook still depends on

plugins/source-control/.claude-plugin/plugin.json no longer declares worktree_create_gate_enabled, even though origin/main (PR #1970, merged into this branch at commit fedcde6) added it, and the hook script + its test suite still reference it.

• git diff origin/main...HEAD -- plugins/source-control/.claude-plugin/plugin.json shows the property being removed relative to origin/main — this branch's merge silently dropped it while bumping the manifest version past it (0.47.0 → 0.47.1).
• plugins/source-control/hooks/worktree-create-gate.sh#L38 and #L62 still read CLAUDE_PLUGIN_OPTION_WORKTREE_CREATE_GATE_ENABLED, and worktree-create-gate.test.sh still sets it directly — so the code and tests assume the manifest declares this knob.
• plugins/source-control/.claude-plugin/plugin.json#L169-L178 shows babysit_worktree_root and worktree_root still present, with worktree_create_gate_enabled missing between them (it sat there in origin/main's 0.47.0).
• The 0.47.1 CHANGELOG entry only documents the hook-utils.sh sync change, not this removal — so it isn't an intentional deprecation, it's a merge-conflict-resolution artifact.

This is squarely a code-review-lane concern (manifest correctness / maintainability, CLAUDE.md's "Configurable without editing the plugin" rule — userConfig is how a consumer discovers and sets this option without forking), not a security issue: the hook's ${CLAUDE_PLUGIN_OPTION_WORKTREE_CREATE_GATE_ENABLED:-true} still fails safe (enabled) at runtime either way, so nothing is exploitable — but a consumer can no longer see or set the opt-out through the plugin's declared config surface, and scripts/sync-hook-utils.sh --check-bump / check-changelog-parity.sh wouldn't catch this since it's unrelated to the hook-utils sync they gate.

Fix this →

Everything else

• Architecture, error-handling, and test-coverage decisions in lib/hook-utils.sh (resolve_read_slice fixed-point arithmetic, printf -v discipline, buffer_stdin's validated-flag reuse of the json_complete verdict, NUL-separated wire format for jq_fields, CR-stripped-after-jq ordering) remain well-justified and unchanged from the version already reviewed in depth.
• All 15 plugin-synced hook-utils.sh copies remain byte-identical to lib/hook-utils.sh; manifest/changelog version bumps for those 15 plugins are consistent, mechanical, and correctly gated.

[claude]

Claude finished @kyle-sexton's task in 1m 2s —— View job

---

Security review of PR #1979 (re-run at 6ba4eb9)

• Diff current HEAD against last-reviewed commit (fedcde6) to see what's new
• Review any new security-relevant changes
• Post findings

Scope reviewed: lib/hook-utils.sh, lib/hook-utils.test.sh, and the 16 synced plugins/*/hooks/hook-utils.sh copies + their plugin.json/CHANGELOG.md bumps — the same scope as the prior two security passes on this PR. No workflow files are touched.

No new security-relevant changes since the last full review. git diff fedcde6..6ba4eb9 -- lib/ 'plugins/*/hooks/hook-utils.sh' is empty — every security-scoped file is byte-identical to the version already reviewed. The new commit (6ba4eb9) is a merge of origin/main (bringing in #1981 session-flow work and unrelated claude-ops/guardrails/session-flow bumps); confirmed via git diff origin/main...HEAD --stat that none of those merged-in files are part of this PR's actual diff — they land on main independently and this branch is just catching up.

Findings from the prior passes stand, unchanged:

• hook::resolve_read_slice (lib/hook-utils.sh#L463-L498): the timeout value only reaches $(( )) through ${BASH_REMATCH[1]}/${BASH_REMATCH[3]}, captured by an anchored digits-only regex. No path for the raw, less-trusted string to reach shell arithmetic directly. No injection.
• hook::buffer_stdin's validated-flag reuse of the hook::json_complete verdict (lib/hook-utils.sh#L500-L596): the flag is set only immediately before the loop's break, on the exact same CR-stripped bytes; nothing mutates input in between. Guard hooks (e.g. block-dangerous-git) that gate on this verdict are unaffected, and jq-absent fail-open behavior is untouched.
• New hook::jq_fields (lib/hook-utils.sh#L614-L677): the untrusted payload is passed to jq as stdin data, never spliced into the jq program string — filters are static, call-site-supplied literals. Still no call sites exist anywhere in the repo, so there's no live injection surface today; any future caller must keep passing only static filter strings, never payload-derived ones.
• NUL-separated field parsing reads via process substitution (not $( )) and fails closed on a field-count mismatch rather than returning misaligned values.
• All 16 plugins/*/hooks/hook-utils.sh copies remain byte-identical to lib/hook-utils.sh.

One pre-existing non-security note, unchanged from before: plugins/source-control/.claude-plugin/plugin.json still shows worktree_create_gate_enabled absent relative to main (a merge-artifact from #1970 landing on main after this branch's base) — not a security issue, since worktree-create-gate.sh reads the flag with a fail-safe ${CLAUDE_PLUGIN_OPTION_WORKTREE_CREATE_GATE_ENABLED:-true} default, but worth the author double-checking the rebase carried it correctly.

No CRITICAL, IMPORTANT, or SUGGESTION security findings to report.