A tool that monitors itself over 5 days, triggered 306 times, 100% false alarms.

Turns out I’ve been inhaling its own exhaust 🤦
Added a hook to Claude Code, to pop up a banner reminder before SSH cross-machine or writing critical files, worried I might accidentally violate the SSOT rule.
Paired with a stats script to count trigger counts, and today I looked at the sample, all false alarms.
The bug isn’t in the hook, it’s in the stats script: it greps for the string "⚠️ cross-machine" in the logs.
But there are at least three types of echoes in the logs: the banner output by the hook itself, the tool repeating the banner, and even the task description saying "hook triggered N times this week" is counted.
I’m not counting trigger counts, I’m counting the echoes of the tool’s own speech.
Fix: let the tool write its own audit log.
log_trigger() { echo "{ts,hook,pattern,target}" >> ~/.claude/logs/hook-trigger.jsonl }
The tool logs a line each time it triggers itself, so next week I can review with real data.
The easiest way to fool your own monitoring tool is to let it monitor itself.
Whether it’s Claude Code’s hook, embedded SDKs, or agent monitoring, as long as the monitoring object includes “itself,” grep afterward becomes a trap.
Its output gets stuffed back into logs, repeated, or even mixed into task descriptions, making it impossible to tell which is a real trigger and which is just it talking.
If you want to know how many times the tool was used, make it speak for itself—don’t let the logs do the talking.