Environment
tracedecay 0.0.74, macOS 26.7 arm64, daemon + watchdog installed as user LaunchAgents, 34 registered projects.
Problem
The daemon climbed to 11.6 GB RSS at 40% to 270% CPU and never went idle. RSS grew about 12 MB/s with no plateau, sampled every 8 seconds.
sample <pid> 5 showed the hot path:
McpServer::run_startup_catch_up_sync
indexing::extract_files_isolated
extraction_worker::WorkerPool::extract_files
tracedecay_sessions::runtime::ingest::ingest_user_sources_for_provider
Killing it does not help. launchd KeepAlive and the watchdog restart it within seconds, and catch-up begins again from the start. Progress does not appear to be persisted, so repeated kills give repeated full passes and no forward progress.
Trigger
A home directory had been registered as a project: 7,516 files, 805 MB graph DB, a 1.15 GB WAL that was never checkpointed, and the broadest of 24 fsevents watchers.
After removing that one project and its store, same binary, same machine:
|
before |
after |
| peak RSS |
11.6 GB, still climbing |
1.0 GB, plateaued |
| CPU at 4 minutes |
40% to 90% |
0% |
| catch-up |
never finished |
about 3 minutes |
Side effect
While the daemon was saturated, hooks that call it went from 0.15s to between 2s and 5s. The Codex plugin sets a 5 second hook timeout, so some were killed. Over 7 days: 16 killed Codex hooks, 4 killed Claude Code hooks, counted by pairing hook_invoked against hook_completed in hook_analytics.jsonl.
Ask
A memory ceiling on extraction and session ingest, and persisted catch-up progress so a restart resumes. Registering a home directory is arguably user error, but the daemon having no upper bound when it happens is not.
Environment
tracedecay 0.0.74, macOS 26.7 arm64, daemon + watchdog installed as user LaunchAgents, 34 registered projects.
Problem
The daemon climbed to 11.6 GB RSS at 40% to 270% CPU and never went idle. RSS grew about 12 MB/s with no plateau, sampled every 8 seconds.
sample <pid> 5showed the hot path:Killing it does not help. launchd
KeepAliveand the watchdog restart it within seconds, and catch-up begins again from the start. Progress does not appear to be persisted, so repeated kills give repeated full passes and no forward progress.Trigger
A home directory had been registered as a project: 7,516 files, 805 MB graph DB, a 1.15 GB WAL that was never checkpointed, and the broadest of 24 fsevents watchers.
After removing that one project and its store, same binary, same machine:
Side effect
While the daemon was saturated, hooks that call it went from 0.15s to between 2s and 5s. The Codex plugin sets a 5 second hook timeout, so some were killed. Over 7 days: 16 killed Codex hooks, 4 killed Claude Code hooks, counted by pairing
hook_invokedagainsthook_completedinhook_analytics.jsonl.Ask
A memory ceiling on extraction and session ingest, and persisted catch-up progress so a restart resumes. Registering a home directory is arguably user error, but the daemon having no upper bound when it happens is not.