Claude Code Hooks Worth Texting Yourself For

A Notification hook texts you when Claude needs a decision, and a Stop hook texts you when a turn ends. Neither covers a subagent finishing in the background, and neither warns you before a slow Bash command starts, only after. Wire SubagentStop and a matcher filtered PreToolUse hook alongside what you already have, and you get a heads up before the wait and a signal the moment a delegated task clears, without a text for every routine tool call in between.

We covered the core three events, Stop, StopFailure and Notification, in our earlier guide on texting yourself when a Claude Code task finishes. That setup answers one question well: is the main session done, and did it end clean or with an error? It says nothing about a subagent Claude spun up to handle a side task, and nothing until after a command has already finished running.

Claude Code's hooks reference documents several more events than those three, each tied to a different moment in a session: PreToolUse before a tool call executes, PostToolUse after one finishes, UserPromptSubmit when you submit a prompt, SessionStart and SessionEnd around the session's lifetime, and SubagentStop when a subagent completes (Claude Code hooks reference). Every event carries a shared set of fields on stdin, including a session id, the working directory and event name, plus fields specific to that event, like the tool name and input for PreToolUse (Claude Code hooks reference). Two of those extra events solve the two gaps above directly: a subagent finishing, and a slow command starting.

PreToolUse fires before a tool call runs, and its script can read the exact tool input, including the Bash command itself, from the JSON Claude Code sends on stdin (Claude Code hooks reference). That timing is the point: a text saying a build just finished is useful once it arrives, but a text saying a build is about to start, and tends to take a few minutes, lets you decide whether to wait at your desk or do something else.

The matcher field on a hook entry filters by tool name only, a string like Bash or Write, not by the content of the call. A matcher of Bash already cuts out every Read, Edit and Glob call Claude makes, but it still fires on every single Bash command, from a one second ls to a ten minute test suite. Filtering the rest has to happen inside the script, by checking the command text itself against patterns known to run slow:

#!/usr/bin/env bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | python3 -c "import json,sys; print(json.load(sys.stdin).get('tool_input', {}).get('command', ''))")
SLOW_PATTERN='npm run build|npm test|pytest|go test|docker build|terraform apply|cargo build|rsync |git clone'
if echo "$CMD" | grep -Eq "$SLOW_PATTERN"; then
  SHORT="${CMD:0:60}"
  ~/.claude/notify-beam.sh "About to run: $SHORT"
fi
exit 0

Exiting zero matters as much as the pattern list. A PreToolUse hook that exits with code 2 blocks the tool call and sends its stderr back to Claude as the reason, the right behavior for a safety check but wrong for a heads up (Claude Code hooks reference). The slow command should still run as planned; the text is a courtesy, not a gate.

The two events from the earlier guide sit at the top because they fire rarely enough that no extra filtering is necessary. SubagentStop and PreToolUse sit lower because they fire often, and unfiltered, either one turns a useful idea into a muted thread within a day.

Every hook here calls the same underlying notify script from the basic setup, a curl against Beam's iMessage API with a workspace key read from an environment variable, never pasted into the script itself. A new filter script needs its own test pass before an unattended run, not just confirmation that the underlying send works:

1. Run the PreToolUse filter script by hand with a fake JSON payload on stdin, containing a command from your slow list, and confirm it sends a text.
2. Run it again with a command not on the list and confirm it sends nothing; a filter that texts on everything is no filter at all.
3. Trigger two subagent completions close together and confirm the debounce script's timestamp file is actually written to the path you expect, not silently failing because the directory does not exist.
4. Check Beam's own conversation record for each test message rather than trusting a script's exit code; a queued send is not a delivered one.
5. Leave the full set of hooks running for one real overnight session, and compare what arrived against what you expected: one slow command heads up, one subagent text if applicable, and a final Stop or StopFailure text.

Everything above runs from the outside: a hook watches for a moment in the session and fires a fixed message, regardless of what Claude is thinking at the time. Connecting Claude Code to iMessage through Beam's MCP server is the opposite approach, where Claude itself holds a tool it can call mid session, and decides in the moment whether a text is worth sending, with a draft you can review before it goes out. Our MCP server guide goes deeper into which tools that connection exposes and how permissions scope what the agent can do with them.

Neither approach replaces the other. A hook catches moments you already know matter, a session ending, a subagent clearing, a slow command starting, without asking Claude to decide every time. An MCP connection catches what you cannot predict, because the agent noticed something mid conversation a fixed hook never would. Most setups we build run both: hooks for predictable milestones, MCP for judgment calls.