Stop-Process on WindowsTerminal.exe Killed Every Claude Code Tab We Had

The symptom: four agents, one simultaneous death

Four separate Claude Code agents were running in four tabs of the same Windows Terminal window — one doing a merge, others idle between turns. All four died in the same second. Not crashed with an error each in turn. Not one at a time. Simultaneously, as if something had reached in and pulled the plug on the window itself.

The wrong suspect: a restart two minutes earlier

The obvious first theory: a server restart had run at 01:01, two minutes before the tabs died. Restarts are exactly the kind of event that plausibly cascades into killed processes. It fit the timeline. It was also innocent — and confirming that meant reading the actual transcript instead of trusting the correlation.

The restart at 01:01 was clean: old server stopped, new server up two seconds later, nothing unusual. A worker separate from the restart had opened its own scratch tab at 01:02:31 to verify the restart worked, listed running processes to find that scratch tab's window, and at 01:03:19 killed the PID it found — 12480.

The real bug: a scratch tab and the whole window share one PID

Windows Terminal is one process (WindowsTerminal.exe) hosting every tab inside it, the same way one browser process hosts every tab in your browser. There is no separate OS process per tab. When the worker asked "which process is my scratch tab," the honest answer was the same PID as everyone else's tab — because that's genuinely what a tab is: a view inside one shared window process, not a process of its own.

The worker's intent was narrow: close one scratch window it no longer needed. The tool it reached for, Stop-Process -Id 12480 -Force, doesn't know about intent. It kills the process. The process was the window. The window held four other agents' work.

Forensics: reading the transcript instead of trusting the clock

Nothing in stop.sh, start.sh, the server process, the supervisor, or the reaper had logged a kill at that moment. No crash in the event log. No husk-close line, no reaper line. The only thing that explained a simultaneous death of every tab was a command that targeted the terminal host directly — which meant checking the one place that records every command a session actually ran: its own transcript, timestamp by timestamp, until the exact line that fired at 01:03:19 turned up.

tanks-stage-4 was still making tool calls at 01:03:11 (after the restart) -> ruled out
watchdog logged STALLED at 01:03:35 (an effect, not a cause) -> ruled out
no kill in stop.sh / start.sh / server.py / supervisor / reaper -> ruled out
worker transcript, 01:03:19: Stop-Process -Id 12480 -Force -> exit 137
Get-Process at 01:03:15 in the same transcript: 12480 = WindowsTerminal -> confirmed

The fix: deny the command, and narrow what the reaper is allowed to kill

The fix has two parts, because two different actors can produce the same fatal command: a human or agent typing it directly, and the machine's own automated cleanup (the reaper, the watchdog) doing it by accident.

1. A PreToolUse hook that denies the command outright

A new hook runs before any Bash or PowerShell tool call and checks whether it targets WindowsTerminal — by name, or by a literal PID that a live tasklist lookup says currently belongs to WindowsTerminal.exe.

Running sessions picked the guard up live, no restart needed: a PowerShell probe (Get-Process WindowsTerminal | Stop-Process -WhatIf) was blocked, and a bash probe (kill -0 56636 against the live WindowsTerminal PID) was blocked with the exact reason — "pid 56636 is WindowsTerminal.exe."

2. The reaper and watchdog stopped trusting a remembered PID

The guard covers a typed command. It doesn't cover automation that kills a stored PID from earlier, which is a second, quieter version of the same bug: the reaper used to kill a stuck Claude session's parent process by a PID it had recorded minutes or hours earlier. PIDs get reused by Windows. If that recorded "parent" PID had since been recycled to WindowsTerminal.exe, the reaper would kill the terminal host on its own, with no human in the loop at all.

A recycled PID that now belongs to WindowsTerminal fails both checks: WindowsTerminal isn't a shell, and even if it happened to look like one, a freshly-recycled PID is younger than the agent process it's being blamed for hosting. Either check alone stops the kill.

Proof

• PASS test_wt_guard.py — 15 tests: the exact 01:03:19 command and 6 other kill forms all denied; harmless commands still pass; a live PID lookup correctly names the real WindowsTerminal process before deciding.
• PASS test_reaper_parent_guard.py — 5 tests: the launching shell still gets killed when it should; a non-shell stand-in for WindowsTerminal is left alone; a younger "parent" (the reused-PID case) is left alone.
• PASS live restart with a probe tab open: before the restart, WindowsTerminal PID 56636 hosted a probe tab and 4 agent tabs (6 tabs total); 60 seconds after the restart's watchdog, reaper, and husk-close passes all ran, the same WindowsTerminal PID and the same 4 agent PIDs were still there, no STALLED or husk lines logged.
• PASS the probe tab closed cleanly with wt-send.ps1 -Title probe -Message exit (send exit to the tab's own shell) — WindowsTerminal and the other 4 tabs were untouched.

Related reading

• Two Slashes Killed Our Terminals
• pytest INTERNALERROR: A Standalone test_*.py Script Crashed the Whole Suite