The runtime trace showed why:

python.exe: can't open file
'...\AnnettesHealth\Usersannet.claudehookshub-first-check.py'

The command was written as py -3.13 C:\Users\annet\.claude\hooks\hub-first-check.py, unquoted. Hook commands run through a POSIX shell, so every backslash was consumed as an escape character and the path collapsed into that garbage string. Python couldn't find the file, the hook failed, and nothing surfaced in normal use.

The fix: quote it and use forward slashes, matching the hooks that already worked.

py -3.13 "C:/Users/annet/.claude/hooks/hub-first-check.py"

The second casualty was session-stop-drift-check.py, which watched three Desktop files deleted back in May. That one has been retired along with the whole desktop bookkeeping system.

These are genuinely different problems, and no single check finds all three.

• UTF-8 BOM in a settings file. A single invisible byte at the start makes Claude Code reject the entire file, killing every hook and every permission inside it. PowerShell's Out-File adds one by default. Use Set-Content -Encoding utf8NoBOM.
• Orphaned hooks.json. Hooks are only loaded from the hooks key inside settings.json. A standalone .claude/hooks/hooks.json is never auto-loaded. Four documented hooks sat in one for nearly three months and never fired once.

py -3.13 C:\Users\annet\ClaudeProjects\MyExecAssistant\scripts\audit_hooks.py

Reads every hook across user settings and all project settings, then classifies each one. It reconstructs paths that scripts build at runtime from variables, which is what the naive version missed. It also flags BOMs and orphaned hook files.

• DEAD the script does not exist, this hook can never succeed
• BROKEN unquoted Windows path, the shell eats the backslashes
• STALE script runs but the files it watches are gone
• COLD writes a log or state file that has not changed in 30 days
• DUPE the same hook is registered twice for one event
• UNVERIFIED fails open and writes no log, so a break would be invisible

claude --debug hooks --debug-file trace.log -p "reply with just: ok"

Then search the log for error, canceled, can't open file, and Failed to parse hook output. This is the layer that caught the broken quoting, and no amount of config reading would have found it.

UNVERIFIED means "cannot be proven statically," not "broken." They all fail open and write no log, which is the right default (a broken hook should never block a session), but it means config inspection can never confirm them. Two pieces of evidence say they are fine: the skill-of-the-day hook demonstrably produced output, and the post-fix trace showed every Stop hook completing without error.

To make them self-reporting, each would need one line appending a timestamp to a log on success. The COLD check would then catch any that go quiet. That is a small, optional upgrade, not currently done.

A claude-mem plugin SessionEnd hook reported "canceled" in both traces. That may simply be an artifact of headless mode shutting down abruptly rather than a real defect. Not called a bug until it is seen in an interactive session.