Hook events are lifecycle points to which a deterministic reaction can be attached, and they are more conveniently kept by family than as a flat list. There are session and configuration events, prompt and display, tool lifecycle, agents and tasks, memory and context, file system and worktree, MCP interaction and turn end. The full current list is in the official hooks reference; this reference gives a map of the families and what a hook can do in each.

The key difference between events is what a hook can decide in them. On PreToolUse a hook can allow, modify or block a tool call before it runs - the strongest place for policy. On PostToolUse and PostToolUseFailure it reacts to the result already: formats, tests, audits. UserPromptSubmit lets you check or augment the prompt, and Stop and StopFailure lets you intervene in the turn end. An event's capabilities determine which task it makes sense to attach to it.

Session and infrastructure events give context and provenance. SessionStart, ConfigChange and SessionEnd are handy for environment setup and audit; InstructionsLoaded, PreCompact and PostCompact for tracking the provenance of instructions and continuity on compaction; file-system and worktree events (FileChanged, WorktreeCreate, WorktreeRemove) for reacting to environment changes. Agent and task events (SubagentStart/Stop, TaskCompleted) serve orchestration control. Below is a map of the families and their typical tasks.

The reference should be used with the same caveat as the whole hooks chapter: a hook is programmatic control with your process's rights, so it is reviewed and tested as code. The exact set of events, their input and return codes depends on the version, so before building policy on a specific event you check the official reference and verify the behavior via claude --debug. Matchers are case-sensitive - Bash, not bash - and this is a frequent cause of "the hook does not fire".