概要: 連載第1回で「.claude/ は土台・ガード・拡張の3層で設計する」と言いました。本記事ではその中で一番「事故防止」に効くガード層 = hooks に踏み込みます。.env の Read を二重で遮断、terraform apply を経路付きでブロック、commit に混ざった該当署名を検出、起動時に context を 1 行注入——という 4 つの hook をコード付きで訣ります。

はじめに

Claude Code の permissions は便利ですが、deny ルールだけに頼ると漏れるケースがあります。

• Bash(terraform apply:*) を deny しても、cd terraform/dev && terraform apply のようにシェルに埋められると matcher にひっかからないことがある
• .env は deny していても、Read 以外の経路（Glob でパスを拾って cat されるなど）はロジックが違う
• git commit はコマンド自体は無害なので permissions では手出ししにくいが、中身のメッセージに Claude の署名が混ざることがある

こういう「単純なコマンド名マッチングだけだと足りないケース」に効くのが hook です。hook は tool 呼び出しの前後に shell スクリプトを挿し、実際の tool input を JSON で受け取って判断できる仕組みです。

本記事では、実運用している 4 つの hook を題材に、設計意図・コード・落とし穴を並べておきます。

この記事でわかること

• Claude Code の hook の入出力契約（stdin の JSON / exit 2 = block / exit 1 = warn / stderr の扱い）
• SessionStart で起動時に context を 1 行注入し、「以降の会話全体」にリマインダーを席けるテクニック
• PreToolUse で .env Read と terraform apply / git push --force / rm -rf / をブロックするパターン
• PostToolUse で commit に「Co-Authored-By: Claude」が混入したら警告するパターン
• permissions の deny と hook を二重化する意味

対象読者

• Claude Code をチームで使っていて、hook をこれから書こうとしている人
• 「permissions の deny だけだと何か不安」と感じている人
• 以前「hook を書いたが起動しているのか動いているのかわからない」でデバッグに熟した人

前提条件