[Bug] Background task cleanup with sudo kills entire process tree instead of target process group
Bug Description
Title: Background-task cleanup after the low-memory stop ran sudo kill -TERM -<pgid> and SIGTERM'd every process on the host
Summary
Claude Code stopped a background Bash task because the system was low on memory. About 35 seconds later, a sudo /usr/bin/kill -TERM -<pgid> aimed at that task's process group ran as root. Instead of hitting only that group, every process on the system got SIGTERM: NetworkManager, journald, logind, dbus clients, dockerd, tailscaled, bluetoothd and the desktop session. The user was logged out and the machine looked like it had rebooted. The kernel stayed up.
Environment
- Claude Code 2.1.271 (CLI), model claude-opus-5
- Ubuntu, kernel 7.0.0-34-generic, Cinnamon/lightdm desktop
- procps-ng 4.0.4 (/usr/bin/kill)
- Session ID: 6c3f36a3-27fd-450e-9021-b71a94391da4
Timeline (2026-10-05, UTC)
1. 17:50:28: the model started a background Bash task (b9a1pc3mm) running sudo VAR=... ./<build-script>.sh <target> > "$LOG" 2>&1. The sudo PID was 1785862. sudo credentials were cached from earlier sudo calls in the session.
2. 18:38:22: a task notification arrived: status: killed, "Background command ... was stopped because the system is running low on memory". RAM was nearly full and 1.9 GB of swap was 100% used.
3. 18:38:23: the sudo session for PID 1785862 closed. A root-owned child shell script (PID 1912134) kept running.
4. 18:38:33–34: the model ran a read-only diagnostic (free, ps, pgrep, swapon). This was its last tool call. The transcript has no further assistant tool calls.
5. 18:38:57: the system journal shows:
``
sudo[1938672]: <user> : PWD=<project-dir> ; USER=root ; COMMAND=/usr/bin/kill -TERM -1785862
systemd-journald[908]: Received SIGTERM from PID 1938673 (kill).
NetworkManager: caught SIGTERM, shutting down normally.
tailscaled: got signal terminated; shutting down
dockerd: Processing signal 'terminated'
cinnamon-session: CRITICAL: Unable to start session: Lost name on bus
`
systemd-logind, lightdm, bluetooth, avahi and the user session all died and restarted.
6. **18:38:58**: the session's other background Monitor task exited with code 144. The session went silent.
**Why I believe the harness issued the kill**
- No assistant tool call in the transcript matches it. The model's last call finished at 18:38:34.
- The target is the stopped task's own process group, and the working directory matches the session's.
- The model never used the full /usr/bin/kill path in this session.
- No user hooks, settings or project scripts contain a kill like this.
- No debug log exists for the session, so I couldn't confirm this directly.
**Expected**
After stopping a task, cleanup should affect only that task's process tree. It should never run commands as root through cached sudo credentials without the user knowing. If root-owned children survive, the harness should report them and leave them alone, not escalate with sudo.
**Actual**
A root kill reached effectively every process on the host, as if it were kill -1. The target process group had already lost its leader 34 seconds earlier. I couldn't work out why the kill went wider than that group.
**Impact**
The desktop session was lost along with all unsaved work in other apps. Docker was force-killed and the x11vnc services failed. Every other Claude Code session on the machine was terminated.
**Repro shape (untested)**
1. Cache sudo credentials in a Claude Code session.
2. Start a long sudo <build> as a run_in_background Bash task whose children outlive sudo.
3. Push the system into low memory so the harness stops the task.
4. Watch the journal for a sudo ... kill -TERM -<pgid>` and its blast radius.
Environment Info
- Platform: linux
- Terminal: gnome-terminal
- Version: 2.1.289
- Feedback ID: dd626e07-5359-46da-aaef-8f1ed8b51018
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Sorry this took your whole session down. NetworkManager, journald, tailscaled and dockerd all killed by what was supposed to be a cleanup is a miserable way to get logged out. Two things that should stop a repeat while this gets fixed, set timestamp_timeout=0 in sudoers so a cached sudo can't be reused by anything you didn't type, and run root builds inside systemd-run --scope so cleanup kills a cgroup instead of a process group.
The deeper problem is that the agent decided to run a root level kill on its own and nothing stopped it. I ran into the same thing, which is why I built Vestige. It sits between the agent and the shell, and anything destructive like a root kill has to be approved before it runs, with a record of exactly what tried to run it.
Happy to help you try it if you want.
Hey Sam,
Yeah, I was on my weekly one on one call with my manager in a Google
Meet call when it hit.
So how do I set this up so it doesn't happen again?
Ed
On 2026-10-06 15:57, Sam Valladares wrote:
Hey Ed,
These two commands install Operator Lite, which is free, and turn on blocking.
npx operator-lite
npx operator-lite mode enforce
From then on Operator checks every command your agent tries to run. It blocks the destructive ones it knows before they run and logs every tool call, so you can see exactly what the agent ran and when.
For the build, use a transient service in place of the systemd-run --scope I suggested, since a scope stays a child of whatever launched it.
sudo systemd-run --unit=build-rpi5 --collect ./build-image.sh rpi5
Keep timestamp_timeout=0 in sudoers too, so a cached sudo cannot be reused by anything you did not type.
Tell me what you see after the install and I will help with whatever comes up.
https://github.com/samvallad33/vestige