Windows: per-session PowerShell command-safety AST-parser workers (powershell.exe+conhost.exe) never terminate, accumulate all day under claude.exe

Description

Claude Code (desktop app) spawns one long-lived powershell.exe + conhost.exe pair per Bash/PowerShell-tool invocation — apparently a persistent PowerShell process used by the Rust command-safety layer to AST-parse commands before execution (confirmed via the process's own -EncodedCommand, which decodes to a script whose comments read: "Long-lived PowerShell AST parser used by the Rust command-safety layer on Windows. The caller starts one child process per PowerShell executable variant and then sends newline-delimited JSON requests over stdin").

These processes are meant to be reused across a session, but in practice they are never terminated — not when the originating session/window ends, and not later. They accumulate indefinitely across the day as new sessions are opened, one pair per PowerShell-variant per session, until the app (or machine) is restarted.

This was independently observed and cross-confirmed in two separate Claude Code sessions on the same machine, run by two different users' investigations hours apart, both pointing at the exact same parent PID.

Environment

• Claude Code: 2.1.200 (desktop app)
• OS: Windows 10 Home 10.0.19045
• Shell: Windows PowerShell 5.1 (powershell.exe) — harness invoked variant

Evidence

Get-CimInstance Win32_Process snapshot, filtered to powershell.exe/conhost.exe children of a single Claude.exe helper process (PID 9184):

 PID  PPID  Name            AgeMin  ParentAlive
8908  9184  powershell.exe  668.2   True
9688  9184  powershell.exe  545.3   True
12760 9184  powershell.exe  526.9   True
6564  9184  powershell.exe  419.7   True
8324  9184  powershell.exe  389.0   True
7792  9184  powershell.exe  325.8   True
3720  9184  powershell.exe  324.3   True
7816  9184  powershell.exe  306.5   True
11560 9184  powershell.exe  306.3   True
10560 9184  powershell.exe  299.4   True
7720  9184  powershell.exe  291.5   True
7700  9184  powershell.exe  260.2   True
12956 9184  powershell.exe  260.1   True
6300  9184  powershell.exe  170.8   True
6368  9184  powershell.exe  10.9    True
8000  9184  powershell.exe   4.3    True

(each paired with a matching conhost.exe at the same age — 16 pairs total, oldest 11+ hours old)

Parent chain:

9184  claude.exe  (parent=14248, created 07:55:51 — start of the workday)
14248 claude.exe  (parent=4128, explorer.exe)

None of these processes' command lines reference any specific project/repository path — they are generic per-session command-safety-check workers, not tied to any user script, hook, or statusLine config (verified separately: a repo's own statusLine/hook-spawned pwsh.exe processes do terminate correctly and were not among the accumulated set).

A second, independent investigation on the same machine (different Claude Code session, several hours earlier the same day) found the identical pattern — same parent PID 9184, ~15 pairs at that point, growing throughout the day — plus two long-running children with high accumulated CPU time consistent with the AST-parser workers staying resident and doing periodic work rather than sitting fully idle:

PID 12428: ~714 MB working set, ~8266s CPU time (~11h uptime, ~20% avg CPU)
PID 6632:  ~79 MB working set,  ~4735s CPU time (~11h uptime, ~12% avg CPU)

Impact

• Process/handle count grows unbounded over the course of a workday with normal multi-session usage (dozens of sessions opened/closed without an app restart).
• Two of the accumulated workers were observed consuming sustained non-trivial CPU (12-20% average) for hours, not just idling — i.e. this isn't only a handle leak, it's an active resource drain.
• Over a full day this compounds into dozens of resident processes and measurable steady-state CPU/memory overhead even when no Claude Code session is actively in use.

Expected behavior

The per-session PowerShell AST-parser worker (and its conhost.exe) should be terminated when:

• its owning session/window closes, or
• it has been idle beyond some reasonable timeout,

whichever comes first — rather than persisting for the lifetime of the parent claude.exe app process indefinitely.

Related issues

This looks distinct from but adjacent to:

• #77186 (bare argument-less powershell.exe windows that never close) — different mechanism, these processes do carry a real -EncodedCommand, aren't empty interactive windows, and serve a specific documented purpose (AST parsing for command safety).
• #67888 (taskkill /PID x /T /F hangs and accumulates) — different spawned command entirely, but same broader theme of Windows child-process cleanup not happening on session end.

Happy to provide the full decoded -EncodedCommand payload or additional process/handle detail if useful for triage.