Found live 2026-09-05 when the container OOM-killed a working session (8GB exhausted, swap full, 227MB available).
What happened
36 alive neowolt lodge sessions had accumulated, each holding a ~150-460MB claude process. All but a handful had last_activity == created_at — spawned, boot-prompted, never used. Combined they consumed nearly the whole container.
Two distinct bugs compound here:
1. Lodge sessions spawn in identical pairs
session-boot.log shows neowolt sessions created two-at-a-time in the same second, repeatedly, across many hours:
[2026-09-04T22:03:16] spawn session: neowolt-wild-bark-4c5f33
[2026-09-04T22:03:16] spawn session: neowolt-broad-hollow-b4e08e
[2026-09-04T22:04:26] spawn session: neowolt-dense-fur-f798f8
[2026-09-04T22:04:26] spawn session: neowolt-slappy-oak-ead165
[2026-09-05T00:35:03] spawn session: neowolt-silty-birch-cea195
[2026-09-05T00:35:03] spawn session: neowolt-snug-creek-653bf8
Every trigger produces exactly two sessions, adapter=lodge, wolt=neowolt (the default wolt). neowolt's wolf.json crons are empty, so it isn't a scheduler. The pattern (default wolt + lodge adapter + doubled request + clustered around times the owner was active on their phone) suggests a lodge/PWA client firing POST /sessions/new/lodge twice per open — e.g. a duplicated event handler, a service-worker replay, or a retry racing the first request.
2. Idle sessions are never reaped
The oldest untouched pair was 21 hours old and still holding a live claude process. Whatever the vulture's idle criteria are, sessions that have never received a message after boot evade them (or the vulture isn't running/acting). A session with zero activity since creation is the easiest possible reap candidate.
Impact
Memory exhaustion → OOM killer took out an unrelated active session (exit 137). Any long-running container will eventually hit this if a client double-spawns on a regular gesture.
Stopgap applied
Stopped the 32 sessions >1h old with zero post-boot activity via POST /sessions/{name}/stop (kept the 4 recent ones). Freed ~3.5GB.
Suggested fixes
🤖 Generated with Claude Code
Found live 2026-09-05 when the container OOM-killed a working session (8GB exhausted, swap full, 227MB available).
What happened
36 alive
neowoltlodge sessions had accumulated, each holding a ~150-460MB claude process. All but a handful hadlast_activity == created_at— spawned, boot-prompted, never used. Combined they consumed nearly the whole container.Two distinct bugs compound here:
1. Lodge sessions spawn in identical pairs
session-boot.logshows neowolt sessions created two-at-a-time in the same second, repeatedly, across many hours:Every trigger produces exactly two sessions, adapter=lodge, wolt=neowolt (the default wolt). neowolt's
wolf.jsoncrons are empty, so it isn't a scheduler. The pattern (default wolt + lodge adapter + doubled request + clustered around times the owner was active on their phone) suggests a lodge/PWA client firingPOST /sessions/new/lodgetwice per open — e.g. a duplicated event handler, a service-worker replay, or a retry racing the first request.2. Idle sessions are never reaped
The oldest untouched pair was 21 hours old and still holding a live claude process. Whatever the vulture's idle criteria are, sessions that have never received a message after boot evade them (or the vulture isn't running/acting). A session with zero activity since creation is the easiest possible reap candidate.
Impact
Memory exhaustion → OOM killer took out an unrelated active session (exit 137). Any long-running container will eventually hit this if a client double-spawns on a regular gesture.
Stopgap applied
Stopped the 32 sessions >1h old with zero post-boot activity via
POST /sessions/{name}/stop(kept the 4 recent ones). Freed ~3.5GB.Suggested fixes
last_activity == created_at && age > thresholdas a reap signal.runningstate has the same stale-claim problem (flagged 2026-09-04, growth-chart).🤖 Generated with Claude Code