Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

perf(guardrails, eol-normalizer, typos-format): about 440 ms of hooks per Edit/Write across three node-to-bash hops

オープン
  • 何か問題がありますか？
#6,635 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
30/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
活発
技術スタック
javascript, shell
領域
devtools, performance

調査の方向性

Start with the three hooks.json files (plugins/guardrails, plugins/eol-normalizer, plugins/typos-format) and the shared hooks/exec-bash.mjs launcher that each one invokes through node. Read how exec-bash.mjs resolves the Git Bash path on Windows before changing any registration. Done means the combined PostToolUse runner runs EOL then typos in one bash process, the existing eol-normalizer and typos-format tests pass, and a CRLF file written by Write ends LF-only. Confirm the design with a maintainer first, since the issue asks to keep the PreToolUse guards synchronous.

索引モデルが issue の本文から書いたものです。

説明

needs-human needs-triage

Related: #4390 (guardrails Edit/Write process counts), #4391 and #3751 (closed formatter fan-out), #4373 (umbrella).

Problem

Each Edit/Write pays about 440 ms of hook time across three plugins, each starting its own node process that then starts bash:

  • guardrails PreToolUse (secret-pattern-detection.sh, hardcoded-path-check.sh, block-windows-drive-tmp.sh via run-guards.sh): about 220 ms, before the edit.
  • eol-normalizer PostToolUse: about 205 ms.
  • typos-format PostToolUse: about 205 ms.

The two PostToolUse hooks run in parallel with each other, so the wall-clock after an edit is about the slower of the two, but both add process load and both are node-to-bash hops.

Measured

Method: direct timing on the windows lane (melo-desk-001): canned Edit payload on a copy of a repo README in the session scratchpad, date +%s%N around node exec-bash.mjs <script>, stdin from the payload, 3 runs, latest cached versions.

hook runs (ms)
guardrails PreToolUse Edit trio (guardrails 0.48.1) 218 / 222 / 221
eol-normalizer 0.9.11 204 / 205 / 203
typos-format 0.9.12 206 / 206 / 203
bare node -e 0 52

Context: #4390 measured the guardrails Edit/Write guards at 25 to 87 processes per fire; OTEL in #4373 shows PostToolUse:Edit p50 850 ms, p95 4,249 ms (n=4,081, 7 days).

Where

  • plugins/guardrails/hooks/hooks.json:18-35 (PreToolUse, matcher Write|Edit|NotebookEdit, node hooks/exec-bash.mjs hooks/run-guards.sh secret-pattern-detection.sh hardcoded-path-check.sh block-windows-drive-tmp.sh)
  • plugins/eol-normalizer/hooks/hooks.json:17-35 (PostToolUse Write|Edit, node hooks/exec-bash.mjs --run-if-unset-or-true EOL_NORMALIZER_ENABLED hooks/eol-normalizer.sh)
  • plugins/typos-format/hooks/hooks.json:4-22 (PostToolUse Write|Edit|NotebookEdit, node hooks/exec-bash.mjs --run-if-unset-or-true TYPOS_FORMAT_ENABLED hooks/typos-format.sh)

Example command line: node ${CLAUDE_PLUGIN_ROOT}/hooks/exec-bash.mjs --run-if-unset-or-true TYPOS_FORMAT_ENABLED ${CLAUDE_PLUGIN_ROOT}/hooks/typos-format.sh

Proposed fix

One combined PostToolUse runner for the file-normalizing family (eol-normalizer, typos-format, and the other formatter plugins that match Write|Edit), registered once, running its steps in order in a single bash process (EOL first, then typos, so the second sees normalized bytes), with no node-to-bash hop: register bash with the resolved Git Bash path directly, as exec-bash.mjs resolves it today (#3686/#3708 explain why bare bash cannot be used on Windows).

Keep the secrets/path guards in PreToolUse as blocking hooks: they can deny the edit, and an async hook cannot ("response fields like decision, permissionDecision, and continue have no effect", https://code.claude.com/docs/en/hooks#run-hooks-in-the-background). Only the report-only PostToolUse rows (typos-format reports; #4677 is the earlier decision) may go "async": true. The EOL normalizer rewrites the file, so it must stay synchronous or the model's next Edit races it.

Basis: measured node start-up share (52 of about 205 ms) and bash start-up 29 ms (above); async limits at the URL above; if narrowing at https://code.claude.com/docs/en/hooks#common-fields (already used in guardrails for .md/.sh).

Expected saving

About 150 to 250 ms of CPU per Edit/Write removed (two node processes and two bash starts become one bash), and one fewer process tree for Defender-style scanners to inspect. At 581 Edit fires per day (#4390) that is 1.5 to 2.5 CPU-minutes per day; the wall-clock gain is smaller because the two rows already run in parallel.

Verify after the fix

  • Re-run the three timing commands; the combined runner should land near 100 ms.
  • /harness-ops:observability latency PostToolUse:Edit p50/p95 before and after, 7 days each.
  • Existing eol-normalizer and typos-format tests pass against the runner; a CRLF file written by Write ends LF-only, and a typo is still reported once.
主要言語
Shell
スター
22
フォーク
2
平均マージ
8時間 34分
マージ済み PR（30日）
946

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

melodic-software/claude-code-plugins のほかの issue

melodic-software/claude-code-plugins の issue をすべて見る

似ている issue

Shell/Bash の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。