Summary
On v13.4.0 (post plan-11 0b4611e89), the observer SDK still enters a continuous poison/respawn loop when the model legitimately replies with prose like "No observations to record at this time." for queued tool calls. plan-11 added kill+respawn with preserved pending messages, which prevents data loss — but the root cause asked for in #2749 was the opposite: classify prose-empty as a valid empty result (ack the batch, advance the queue), not count it toward the poison threshold. Because that part was not shipped, every investigation-heavy or low-signal session burns ~1 SDK call every 10–20 s in a respawn cycle that can never converge.
Environment
- claude-mem: 13.4.0 (npm
latest, cache built 2026-05-29 20:45 UTC — includes 0b4611e89)
- Claude Code: 2.1.159
- OS: Linux 6.12.85 (Alpine container, Home Assistant OS add-on)
CLAUDE_MEM_RUNTIME=worker, CLAUDE_MEM_MODEL=claude-haiku-4-5-20251001- SDK authMethod:
Claude Code OAuth token (read from system keychain at spawn)
Reproduction
Any session whose tool calls are investigative (ps, grep, cat, ls) instead of producing concrete code outputs. The observer correctly identifies "nothing decisional to record" and emits prose; parser flags as outputClass=prose/idle; after 3 consecutive invalids → poison + respawn; the fresh SDK session reproduces the same prose for the next batch.
Logs (verbatim, today's session)
[09:54:04] [SDK ] ← Response received (119 chars) (No observations to record — no tool executions or technical findings from the primary session have been provided yet.)
[09:54:04] [PARSER] SDK returned non-XML prose response — ignoring queued batch {outputClass=prose, consecutiveInvalidOutputs=2}
[09:54:11] [PARSER] SDK returned non-XML idle response — ignoring queued batch {outputClass=idle, consecutiveInvalidOutputs=3}
[09:54:11] [ERROR ][SESSION] SDK session poisoned — killing and respawning, pending messages preserved {threshold=3}
[09:54:11] [WARN ][SDK_SPAWN] child emitted error event {errorName=AbortError, errorCode=ABORT_ERR} The operation was aborted.
[09:54:19] [PARSER] SDK returned non-XML idle response — ignoring queued batch {outputClass=idle, consecutiveInvalidOutputs=1}
[09:54:20] [SDK ] ← Response received (49 chars) (no observations - investigation not yet started)
[09:54:20] [PARSER] SDK returned non-XML prose response — ignoring queued batch {consecutiveInvalidOutputs=2}
[09:54:37] [PARSER] SDK returned non-XML idle response {consecutiveInvalidOutputs=3}
[09:54:37] [ERROR ][SESSION] SDK session poisoned — killing and respawning, pending messages preserved
... (repeats every 10–20s for the entire session lifetime)
Daily count from my logs (Linux, same install):
Jun 1: 734 poison events ← investigation-heavy day
Jun 2: 0 ← code-implementation day
Jun 3: 1318 ← investigation-heavy
Jun 4–6: 0 ← code-implementation days
Jun 7: hundreds and counting (current session)
Expected (carried over from #2749)
outputClass=prose matching a well-formed "no observations" acknowledgement should:
- Be treated as a valid empty result for the queued batch (ack, advance queue).
- Not increment
consecutiveInvalidOutputs.
- Not count toward the poison threshold.
Equivalently, the system prompt could pin a contract requiring <observations></observations> even when empty, and the parser would then accept the empty tag — but the current state (prose returned + parser rejects + recovery loop) leaves both ends out of sync.
Impact
- Observations table stalls during low-signal session phases (today: no new rows since 2:34 AM despite an active 2-hour session).
- Continuous Haiku API calls on the user's subscription — every loop iteration costs one observer call.
- Log volume: ~260 KB of WARN/ERROR per session in my case.
Notes
Summary
On v13.4.0 (post plan-11
0b4611e89), the observer SDK still enters a continuous poison/respawn loop when the model legitimately replies with prose like "No observations to record at this time." for queued tool calls. plan-11 added kill+respawn with preserved pending messages, which prevents data loss — but the root cause asked for in #2749 was the opposite: classify prose-empty as a valid empty result (ack the batch, advance the queue), not count it toward the poison threshold. Because that part was not shipped, every investigation-heavy or low-signal session burns ~1 SDK call every 10–20 s in a respawn cycle that can never converge.Environment
latest, cache built 2026-05-29 20:45 UTC — includes0b4611e89)CLAUDE_MEM_RUNTIME=worker,CLAUDE_MEM_MODEL=claude-haiku-4-5-20251001Claude Code OAuth token (read from system keychain at spawn)Reproduction
Any session whose tool calls are investigative (
ps,grep,cat,ls) instead of producing concrete code outputs. The observer correctly identifies "nothing decisional to record" and emits prose; parser flags asoutputClass=prose/idle; after 3 consecutive invalids → poison + respawn; the fresh SDK session reproduces the same prose for the next batch.Logs (verbatim, today's session)
Daily count from my logs (Linux, same install):
Expected (carried over from #2749)
outputClass=prosematching a well-formed "no observations" acknowledgement should:consecutiveInvalidOutputs.Equivalently, the system prompt could pin a contract requiring
<observations></observations>even when empty, and the parser would then accept the empty tag — but the current state (prose returned + parser rejects + recovery loop) leaves both ends out of sync.Impact
Notes
YH=3in bundledworker-service.cjs) still hardcoded; no env override exposed.