[BUG] Windows: internal PID-verification PowerShell probe (1000ms timeout) leaves permanently unkillable zombie processes that lock the project directory

[eking7507-pixel]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Title: Windows: internal PID-verification PowerShell probe (1000ms timeout) leaves permanently unkillable zombie processes that lock the project directory

Environment:

• Claude Code v2.1.218 (native install, claude.exe)
• Windows 10 Pro 10.0.19045
• Windows PowerShell 5.1 (default powershell.exe)

What happens:
Claude Code internally spawns a PID-reuse verification probe:

powershell.exe -NoProfile -Command "(Get-CimInstance Win32_Process -Filter \"ProcessId=<pid>\").CreationDate.Ticks"

with {timeout: 1000} (bundled JS, function c5e / caller Wjr; there is also a
[DateTimeOffset]::new(...CreationDate).ToUnixTimeMilliseconds() variant).

On a loaded machine — e.g. several Claude Code sessions launching at once —
PowerShell 5.1 cold start regularly exceeds 1000ms. The timeout then calls
TerminateProcess while the child is still initializing (blocked in the
conhost/condrv connect, a non-alertable kernel wait). The child becomes a
permanent zombie: 1 thread in Executive wait state, ~23 handles, and it
keeps an open handle to its working directory — which is the Claude session's
project folder. The folder is then locked (cannot be renamed/moved/deleted)
until a true reboot. The paired conhost.exe is orphaned too.

Observed at scale: 11 such zombies accumulated over 3 days on one machine
(all identical command lines, all parents dead, each pinning the project
directory of the session that spawned it).

Kill behavior (the confusing part):

• taskkill /F /PID <pid> → ERROR: ... Reason: There is no running instance of the task.
• Stop-Process -Force (elevated too) → no error, process remains
• Win32 enumeration (Get-Process, Get-CimInstance Win32_Process) and
  Sysinternals handle.exe still show the process
• Killing the paired conhost does not release it
• Only a full kernel-cycle reboot clears them

Why it matters: project folders (user data) get locked for days; users
burn hours on taskkill/elevation attempts that cannot work; the orphans
accumulate silently because nothing reaps them.

What Should Happen?

1. Raise the probe timeout well above PS 5.1 cold-start worst case, or retry
   instead of hard-killing a child that is still in process initialization.
2. Spawn probes in a Job Object with JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE.
3. Spawn probes with cwd = a temp/system dir, NOT the project directory, so a
   stuck probe can never pin user data.
4. Prefer a native API (NtQuerySystemInformation / GetProcessTimes on an
   opened handle) over shelling out to PowerShell for process creation time.

Error Messages/Logs

Steps to Reproduce

launch 4+ Claude Code sessions simultaneously on a
cold-booted Windows 10 machine with default PS 5.1; inspect
Get-CimInstance Win32_Process -Filter "Name='powershell.exe'" for
CreationDate.Ticks command lines whose parents are dead; check locked
project dirs with handle.exe <folder>.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

Claude Code v2.1.218

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Title: Windows: internal PID-verification PowerShell probe (1000ms timeout) leaves permanently unkillable zombie processes that lock the project directory

Environment:

• Claude Code v2.1.218 (native install, claude.exe)
• Windows 10 Pro 10.0.19045
• Windows PowerShell 5.1 (default powershell.exe)

What happens:
Claude Code internally spawns a PID-reuse verification probe:

powershell.exe -NoProfile -Command "(Get-CimInstance Win32_Process -Filter \"ProcessId=<pid>\").CreationDate.Ticks"

with {timeout: 1000} (bundled JS, function c5e / caller Wjr; there is also a
[DateTimeOffset]::new(...CreationDate).ToUnixTimeMilliseconds() variant).

On a loaded machine — e.g. several Claude Code sessions launching at once —
PowerShell 5.1 cold start regularly exceeds 1000ms. The timeout then calls
TerminateProcess while the child is still initializing (blocked in the
conhost/condrv connect, a non-alertable kernel wait). The child becomes a
permanent zombie: 1 thread in Executive wait state, ~23 handles, and it
keeps an open handle to its working directory — which is the Claude session's
project folder. The folder is then locked (cannot be renamed/moved/deleted)
until a true reboot. The paired conhost.exe is orphaned too.

Observed at scale: 11 such zombies accumulated over 3 days on one machine
(all identical command lines, all parents dead, each pinning the project
directory of the session that spawned it).

Kill behavior (the confusing part):

• taskkill /F /PID <pid> → ERROR: ... Reason: There is no running instance of the task.
• Stop-Process -Force (elevated too) → no error, process remains
• Win32 enumeration (Get-Process, Get-CimInstance Win32_Process) and
  Sysinternals handle.exe still show the process
• Killing the paired conhost does not release it
• Only a full kernel-cycle reboot clears them

Why it matters: project folders (user data) get locked for days; users
burn hours on taskkill/elevation attempts that cannot work; the orphans
accumulate silently because nothing reaps them.

Suggested fixes:

1. Raise the probe timeout well above PS 5.1 cold-start worst case, or retry
   instead of hard-killing a child that is still in process initialization.
2. Spawn probes in a Job Object with JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE.
3. Spawn probes with cwd = a temp/system dir, NOT the project directory, so a
   stuck probe can never pin user data.
4. Prefer a native API (NtQuerySystemInformation / GetProcessTimes on an
   opened handle) over shelling out to PowerShell for process creation time.

Repro sketch: launch 4+ Claude Code sessions simultaneously on a
cold-booted Windows 10 machine with default PS 5.1; inspect
Get-CimInstance Win32_Process -Filter "Name='powershell.exe'" for
CreationDate.Ticks command lines whose parents are dead; check locked
project dirs with handle.exe <folder>.

[anselpereira010905-stack]

I Want to solve this assign me this

[raykuo998]

Hit this too, same call site, independently measured on a different machine — adding scale data since mine is an order of magnitude worse than the 11 reported here.

Environment: Windows 11 ARM64 (Snapdragon X2 Plus, 10 cores, 31.6 GB), uptime 7d18h, 24 concurrent claude.exe sessions, native install.

Count: 128 leaked powershell.exe, all with the same command shape:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -Command
  "(Get-CimInstance Win32_Process -Filter \"ProcessId=69712\").CreationDate"

What I verified:

• This call site only. Of the 1002 entries Get-Process returns, 874 are genuinely alive and 128 have exited — and all 128 are this one command. No other image (conhost, cmd, node, claude) has a single un-reaped entry, so it is not a general spawn-hygiene problem.
• Parent is always a live claude.exe (resolved via Win32_Process.ParentProcessId for each).
• Age: min 1.5 h, p25 10.5 h, median 11.5 h, max 22.2 h. The query they run finishes in well under a second, so they have been in this state for hours.
• CPU: avg 0.28 s, max 0.41 s per process — idle, not stuck doing work.
• Frozen, not churning: two snapshots 20 s apart returned the identical 128 PIDs — none gone, none new. That is an accumulating leak, not a spawn loop.
• Already exited but not reaped: (Get-Process -Id N).HasExited is True, yet Get-Process still lists them; Stop-Process -Id N fails with "Cannot find a process with the process identifier N". The handle owner never closed them, so the user cannot clear them — only exiting the owning sessions or rebooting does.

I did not check whether mine hold a handle to the project directory as described here, so I can't confirm the directory-lock half of this report; the leak and the call site match exactly.

Cheapest fix from the outside looking in: a process-creation-time lookup does not need a shell at all — OpenProcess + GetProcessTimes (or an existing native binding) gets the same value in-process with no child to reap and no conhost. Failing that, pwsh starts faster than the legacy WindowsPowerShell\v1.0\powershell.exe, which would at least stop the 1000 ms timeout from firing so often.