Cleanup for what your hook created
Your WorktreeCreate hook built an isolated checkout. When Claude Code tears it down, WorktreeRemove runs. The hooks reference names three moments: you remove a --worktree session, a worktree-isolated subagent finishes, or a background session whose worktree the hook created is deleted. There is no matcher, so every handler runs on all three. The payload carries worktree_path, the absolute path your create hook returned.
The reference does not say whether the directory is removed before the hook finishes or after.
Failure is visible only in debug mode
You cannot veto removal on this event. Exit 0 lets cleanup proceed. Exit 1, exit 2, and every other code cannot block removal, and a hook that fails is visible only when debug mode is on. JSON output fields are discarded, systemMessage and continue included. There is nothing for the hook to decide. There is only work to do before the directory goes.
Your remove hook drops the test database the create hook made. One day the credentials rotate and the drop fails.
The worktree goes away as it always does. Nothing tells you the database is still there. Failures on this event reach neither you nor Claude unless debug mode is on, and by the time you notice, there are a dozen of them.
Log from inside the hook to a file you check, because that file is the only place the failure will be.
Module 08 covers when a subagent’s worktree is cleaned up, and module 09 lists this event among those that cannot block.