Hi Kevin. I'm debugging this as the user of the Mac. Finder and other existing applications are FSEvents clients, and the CPU/memory problems predate the diagnostic monitoring. In fact, they were the reason I started doing it. The monitor I added samples fseventsd once a minute. A notification test briefly starts fswatch on a small private probe directory, creates a file, measures the notification delay, and stops the listener. That listener isn't watching the Bazel trees. Then it does a cursor/record inspection by reading the daemon's memory without suspending it or writing. Probe only. I dont have a reliable files/sec or FSEvents/sec figure for the build trees. There is substantial file creation and removal during builds; the fs_usage counts I have are syscall counts, so they wouldn't establish that rate. I haven't isolated which existing subscribers need to watch those trees or whether their watches can be narrowed. That's up to them, and I dont have any direct control there. But heavy use shouldn't really break things. What I need is for normal file-change notifications to keep working, including Finder/Desktop updates, without the sudden memory bloat and CPU load. I'm still treating the Desktop symptom separately. My concern with the cleanup code is that, once the cursor stops, zero-reference records seem to accumulate until a resize resets it. At the maximum table size, that recovery route is no longer available and fseventsd begins accumulating memory and CPU like a runaway snowball.