[Bug] Taskkill command issue - model terminated the user's editor with a broad taskkill filter

Bug Description

Bug report: model terminated the user's editor with a broad taskkill filter

Written 2026-10-15 17:45:32. Category: model behavior (destructive action), not a product defect. Project, plant and user names are anonymized (PLANT1, <project-folder>); the mechanism is unchanged.

Summary

While testing a Java GUI jar, the model ran taskkill /F /FI "WINDOWTITLE eq PLANT1*" on Windows to close the app it had just started. The filter matched the VS Code window (whose title started with the active tab name Plant1_gui_alignment_briefing…), so VS Code was force-killed: six windows, one process, no exit save, no confirmation. The app the model meant to close was not matched at all.

What happened

• Environment: Claude Code 2.1.299 running inside the VS Code extension, Windows 11, Git Bash tool, session 685a54f7-b17f-4bb2-8aff-b3844a534d31.
• Command (2026-10-15 16:25:00.181): start java.exe in the background, save $! to a pid file, wait 12 s, tasklist | grep -c java.exe, then taskkill //F //FI "WINDOWTITLE eq PLANT1*" > /dev/null, then a PowerShell Get-CimInstance Win32_Process listing the test's java.exe PIDs (listing only, after the kill).
• Result (16:25:14): all VS Code windows closed at once. A silent VS Code update that had been waiting since 10:20:33 for the application mutex then completed (16:25:14.785 to 16:25:26) and did not reopen anything.
• Why the filter matched: WINDOWTITLE matching is case-insensitive and PLANT1* means "starts with PLANT1". VS Code's default title starts with the active tab name. The JavaFX app never set a window title, so it was not matched and stayed open.
• What the model had instead: the background process PID (saved in pid) and its command line (the jar path), via Get-CimInstance.

What was and was not established

• Written in logs: the command and its timing; the update log; the active tab at 16:25:07 (webview_focused for that session); no window.title in the user's settings.
• Deduced, not logged: the exact system window title at 16:25:14.
• Not found: any reasoning before the command (the preceding thinking block was empty), any earlier attempt to resolve the Windows PID, or any check of what the filter would select.
• Impact: limited. No project file had unsaved changes. One untitled scratch tab held an irrelevant query. Six windows had to be reopened by hand.

Expected vs. actual

• Expected: terminate only the process the model started, identified by PID or by its command line, and preferably without /F; list what a filter selects before killing; do not discard the command's output.
• Actual: a title-based, force-kill filter on an unverified assumption about the app's window title, with output discarded.

Repro shape

On Windows, with VS Code open and an editor tab whose name begins with a string X, ask the model to launch a GUI test app and close it afterwards. If the model reaches for taskkill /F /FI "WINDOWTITLE eq X*" (or /IM, or Stop-Process -Name), it can kill the user's editor or any other program.

Suggestions

• Treat process termination by window title or by image name as a destructive action that needs explicit confirmation, or steer the model to kill only PIDs it started.
• Consider a built-in warning in the Bash/PowerShell permission flow for taskkill /FI and /IM with /F.

Mitigation applied by the user

A global instruction in the user's ~/.claude/CLAUDE.md (written 2026-10-15 17:18:03) forbids killing by title or name and allows only taskkill /PID for processes the model started. This is an instruction, not an enforced block.

Environment Info

• Platform: win32
• Terminal: windows-terminal
• Version: 2.1.300
• Feedback ID: dc9f6400-6db6-48df-8ceb-eefb4b8409ad