Agent chaosAs reported·22 Oct 2026
Claude Code's placeholder PID of -1 kills every process its user owns, including itself
As reported One person’s public account. We couldn’t independently confirm it, and we’ll update this if the facts change.
A developer says a Claude Code subagent left a -1 placeholder in a SIGKILL cleanup line, then ran it, killing every process they owned: tmux, other Claude sessions, the desktop.
This is one person's account in a bug report on GitHub, not independently confirmed.
What happened
On Linux, a developer had several Claude Code sessions running inside tmux, plus a remote-control session, with Opus as the model. A background subagent was writing a throwaway Playwright browser benchmark in Node. Its first version saved the browser server's process ID and, in its cleanup step, sent that process SIGKILL, the signal that can't be caught or ignored.
How it went wrong
While refactoring, the agent switched to a different way of launching the browser and swapped the saved ID for a placeholder: -1. It left the cleanup line exactly as it was. On Linux, sending a signal to -1 doesn't mean 'nobody'. It means every process you're allowed to signal. Then it ran the script straight away, with a 60-second timeout.
Everything owned by the developer's user died in the same second: the user service manager, the tmux server, every other Claude Code session on the machine, the GNOME desktop and Chrome. The machine itself stayed up, but the whole user session was gone. The system journal the developer shared shows the kill and every session for the user being removed at once, with no out-of-memory activity and no reboot.
Why nobody noticed
The kill also took out the subagent and its parent session, so nothing inside Claude Code ever recorded it. The subagent's transcript simply stops one minute before the kill. The developer had to piece it together from the system logs.
What they're asking for
They call it a model mistake that the harness failed to contain. Blocking commands by their text can't catch it, they point out, because the kill happened inside a Node script, not in a shell command. They want Bash tool commands run in their own process namespace on Linux, so a kill(-1) can only reach the command's own children. For the model side, they suggest never using -1 or 0 as a placeholder ID and checking that an ID is a positive number before any kill. At the time of writing the issue is open.
Our take
This is our opinion. It's a perfect example of why text filters aren't a sandbox: the dangerous bit was one innocent-looking number inside a file. If several agents share your login, one bad cleanup line can take them all down. Run agents as a separate OS user or in a container, so their blast radius ends at their own processes.
A sandbox has to work at the OS level. Your agent's mistakes won't always look like dangerous commands.
