Kevin, adding another case from an M4 MacBook. I’m investigating this as the user of the affected machine. The memory and swap growth keeps returning after normal restarts. Current setup, verified October 25: macOS 27.0.1 (26A434). Backblaze 10.0.3.1076, Continuous backup enabled. Codex desktop 26.1021.31345, build 21828, installed as ChatGPT.app. Claude Code and local indexing/collection tools are also running. No NAS or external filesystem is currently mounted. The clearest observations: October 17: fseventsd showed approximately 36G in top’s MEM column, total system swap was 45.5 GiB, and free disk space was down to 3.18 GiB. After a normal restart, fseventsd was approximately 6.3 MiB RSS and system swap was zero. October 22: another episode reached approximately 60G MEM for fseventsd, with 67 GiB of total system swap and only about 103 MiB free disk space. Following the next boot, fseventsd was approximately 7.4 MiB RSS and swap was zero. October 25: on the same boot, fseventsd grew from a rounded 27G to 29G MEM. Allocated system swap increased from 33 to 35 GiB; free space was 19.62 GiB at 16:53 UTC. MEM and RSS are different measurements. The daemon’s MEM and compressed-memory readings also overlap; I’m not adding them together. Total system swap includes other processes, so I’m not attributing all of it to fseventsd. I initially suspected Backblaze because of the timing. During an approximately 2.5-hour pause on October 23, its transfer/index workers exited and sampled fseventsd CPU fell to about 0.5%, but approximately 13 GiB of compressed daemon memory remained. There was no reboot before that comparison, so it does not establish whether Backblaze triggered the accumulation or merely contributed activity. A short diagnostic sample showed notification processing more active than journal writing. A recent five-minute log window did not show an overflow or identify a responsible client. The pattern resembles the retention problem discussed here, but I have not measured the cleanup cursor or zero-reference records and cannot confirm the same mechanism. What supported, narrowly scoped diagnostics would help distinguish excessive client event retention from a cleanup failure inside fseventsd, without disabling SIP? What should be captured while the daemon is already bloated, before restarting? How can I identify the actual event-producing paths and subscriber scopes without assuming that a running process or its working directory is responsible? Is there a macOS build with a known fix, or should a separate Feedback report reference FB25090184 and FB25224901?