#4087·claude-mem

Worker broadcasts processing status in a tight loop while SDK auth is failing: 770k lines / 111 MB, up to 4,959/min

Author: josegccorreaCreated Sep 14, 2026Updated Sep 14, 2026

Environment: claude-mem 13.24.23, macOS (Apple Silicon), runtime worker.

Summary

When the SDK query fails with Not logged in · Please run /login, the worker keeps broadcasting processing status in a tight loop. The status line is written at INFO on every iteration, so a transient auth failure becomes a disk-space incident.

[INFO ] [WORKER] Broadcasting processing status {isProcessing=true, queueDepth=N, activeSessions=N}
[ERROR] [PARSER] SDK authentication failed; run /login to preserve queued batch {outputClass=prose, remediation=/login, preview=Not logged in · Please run /login}

Evidence — the correlation is exact

Across 11 log files, heartbeat volume is non-zero if and only if auth errors are non-zero. No exceptions:

Log Size Lines Broadcasting processing status [ERROR] [PARSER] auth
2026-09-09 (spans 09-08 → 09-14) 111 MB 870,868 769,807 11,467
2026-09-01 32 MB 290,294 83,633 1,080
2026-09-14 4 MB 27,751 1,572 114
09-05, 06, 07, 08, 10, 11, 12, 13 1–8 MB 0 0

Peak rate: 4,959 broadcasts/min (~83/s). Roughly 70 heartbeats per auth error.

Days with no auth failure stay at 1–8 MB. The logging volume is entirely a function of the stuck state, not of normal activity.

Impact

A transient auth gap — I hit one while running unrelated OAuth flows — produced 325 MB of logs that I had to prune manually. There is no rotation, so files accumulate indefinitely (mine went back to 2026-07-08, 67 files).

Suggested fix

Either back off the broadcast while isProcessing is blocked on a failure, or demote the status line to DEBUG. The auth failure itself is already reported once per batch, which is the useful signal.

Related

  • #3928 (closed) — same class of failure, different loop (Chroma retry without backoff).
  • #3415 (closed) — "daemon logs to its startup-date file forever" still reproduces on 13.24.23: the file named 2026-09-09.log contains entries from 2026-09-08 21:10:42 through 2026-09-14 15:51:42.