Background-agent daemon self-SIGKILLs its process group (kill(0, SIGKILL)) every ~50s, killing FleetView agents — 2.1.195 & 2.1.196

Summary

On a headless Linux dev box, the background-agent daemon (claude daemon run --origin transient, spawned on demand by claude agents) self-terminates its entire process group with kill(0, SIGKILL) on a ~50-second idle timer. Because FleetView agents and background-task workers live in that process group, they are hard-killed every ~50s and vanish. A new transient daemon is immediately respawned by the client, so the daemon "flaps" indefinitely (699 starts in the current log, only 53 graceful shutdowns → ~646 silent self-kills).

This started after a routine reboot following a disk-size increase and has proven immune to every recovery attempt (see below). The same behavior reproduces on 2.1.195 and 2.1.196.

Environment

• OS: Ubuntu 24.04.4 LTS, kernel 6.8.0-124-generic
• RAM: 11 GiB (cloud VM, 2 vCPU)
• Claude Code: 2.1.195 and 2.1.196 (both affected)
• Daemon: origin=transient (a persistent service was never installed; daemon --help states "Service install is disabled in this version")
• Usage: claude agents (FleetView) plus several background automation loops, all in the same workspace (/home/eden/code/Derive) sharing one per-workspace daemon.

Root cause (captured via strace)

Attaching strace to a live daemon caught the death:

16:33:07.560666 kill(0, 0)              = 0     <- repeated liveness probes
16:33:07.560834 kill(0, SIGKILL)        = ?     <- signals its OWN process group
16:33:07.583974 +++ killed by SIGKILL +++

kill(0, SIGKILL) sends SIGKILL to the caller's entire process group (POSIX). The daemon appears to use this as its idle-teardown mechanism, which hard-kills every worker/agent sharing its process group. Because it's SIGKILL, there is no graceful shutting down log line — the death is silent.

Symptoms / evidence

• Daemon restarts every ~52s (all origin=transient, all workers=0 at start):

``
T02:50:20 T02:51:14 T02:52:06 T02:52:59 T02:53:51 T02:56:37 T02:57:30 T02:58:12
``

• Lifetime of daemon.log: 699 daemon starts, 53 graceful shutdowns → ~646 silent self-kills.
• The daemon self-kills even while a client is connected and reported as "holding this daemon open" in claude daemon status, so it is not simple last-client-disconnect behavior.
• The same version (2.1.195, origin=transient) ran stable for 3 days immediately before the triggering reboot (uptime=266051s), so this is not inherent to the version — a continuously-active agent kept it alive back then.

What triggered it

A reboot right after increasing the VM's disk size. Before that reboot the daemon was stable (3 days on 2.1.195, then 2.25h on 2.1.196). Every daemon since the reboot flaps.

Ruled out (each verified)

• OOM / memory: earlyoom logged zero kills; kernel shows no OOM; all cgroups memory.max=max with oom_kill 0; ~5 GiB available.
• External killer: no pkill/cron on a ~50s cadence; strace shows the daemon killing itself, not an external signal.
• Version: identical on 2.1.195 and 2.1.196; 2.1.195 was stable for 3 days pre-reboot.
• Automation loops: still flaps with all loop services stopped; daemon isn't in their cgroup.
• Disk / FS: root 53% used, mounted rw, filesystem correctly resized, no I/O errors.
• Clock: synced, no skew.
• cgroup / systemd limits: none applicable to the daemon's scope.

Attempts that did NOT fix it

Version downgrade (196→195), pausing loops, full clean restart (kill all claude + clear /tmp/cc-daemon-1000 + daemon.lock), soft reboot, full VM power-cycle, and clearing the persistent roster (~/.claude/daemon/roster.json). It flaps again within ~50s in every case.

Note (possibly related, possibly a red herring)

The persistent roster ~/.claude/daemon/roster.json contained worker entries with pid: 0 (5 of 9 entries were dead/ghost). Given the death is kill(0, …), a roster reap iterating a pid:0 entry seemed a plausible trigger — but scrubbing the roster to a clean state did not stop the flapping, so the idle self-kill appears independent of roster contents. Flagging in case the pid:0 entries are a separate corruption bug (a corrupt roster surviving the unclean shutdown may be how the trigger persists across reboots).

Impact

FleetView background agents and in-session background tasks are hard-killed roughly every 50 seconds on this machine, making claude agents unusable. It also disrupts unrelated claude sessions whose background tasks share the daemon.

Request

• The idle-teardown should not kill(0, SIGKILL) (SIGKILL to the whole process group) — it kills live/idle agents and gives no chance for graceful shutdown or logging.
• Please advise how to (a) disable/lengthen the transient daemon's idle timeout, or (b) run a persistent (non-idle-reaping) daemon, given "Service install is disabled in this version."