Module hooks 

Lifecycle hooks: user commands that attach to the loop without touching it.

Three events. pre_tool runs before the approver and can deny a call; post_tool observes a completed call; session_end fires when a front-end closes a recorded session. Each hook is a shell command run as the user in the workspace, with the event payload as one JSON object on stdin.

Two policy decisions worth stating out loud:

• pre_tool fails closed. Exit 0 allows; exit 2 denies with the hook’s output as the reason; any other exit, a spawn failure, or a timeout also denies. A policy hook that cannot run and silently allows is the silently-degrading-sandbox mistake with a different spelling. Observers (post_tool, session_end) are best-effort: their failures are logged and swallowed, because they cannot be load-bearing.
• Hooks run before the human. A pre_tool denial never reaches the approver — mechanical policy is cheaper than an interruption, and a hook cannot be talked into clicking yes. The trifecta interlock still sits in front of everything; hooks do not replace it and cannot loosen it.

The order in config is the order they run. For pre_tool, the first denial wins and later hooks do not fire.

Structs

HookSet

The validated hook set for one process. Empty is the common case and free.

Enums

HookVerdict

What a pre_tool hook decided.