[Bug]: Periodic Claude provider refresh accumulates orphaned tasklist.exe/findstr.exe processes on Windows

[HMBSbige]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Run T3 Code on Windows with the Claude provider enabled.
2. Leave the default provider health refresh enabled. T3 normally performs this refresh about every five minutes.
3. To trigger a refresh manually, open Settings → Providers and click Refresh provider status.
4. During and immediately after each refresh, inspect the process tree with:

$names = @('claude.exe', 'cmd.exe', 'tasklist.exe', 'findstr.exe')

Get-CimInstance Win32_Process |
  Where-Object { $names -contains $_.Name } |
  Select-Object Name, ProcessId, ParentProcessId, CreationDate, CommandLine |
  Sort-Object CreationDate

5. Repeat the scheduled or manual refresh for two or three capability-probe cycles. For manual refreshes, wait until the capability cache expires, approximately five minutes, before triggering the next check.
6. Compare the process snapshots and count the tasklist.exe and findstr.exe processes that remain after each refresh.

Expected behavior

Each provider refresh should clean up the complete Claude capability-probe process tree. The tasklist.exe and findstr.exe processes started by Claude's IDE detection should exit when the probe completes, times out, or is aborted. Their number should return to the previous baseline after every refresh.

Actual behavior

The periodic Claude provider refresh starts a capability probe. During the probe, Claude's IDE detection runs a command similar to tasklist | findstr /I "Code.exe Cursor.exe ...". After the refresh finishes or the probe is aborted, tasklist.exe and findstr.exe processes can remain alive. Subsequent refreshes may leave additional instances behind, causing leftover processes to accumulate over time. This is a persistent process-lifecycle problem, not just a transient console-window flash.

Impact

Major degradation or frequent failure

Version or commit

0.0.35

Environment

No response

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

In T3 Code, open Settings → Providers, expand the Claude provider instance, and add the following under Environment variables:

FORCE_CODE_TERMINAL=1
CLAUDE_CODE_AUTO_CONNECT_IDE=0
CLAUDE_CODE_IDE_SKIP_AUTO_INSTALL=1

[HMBSbige]

I found another related symptom while investigating this issue. On Windows, starting or refreshing the Claude provider can also launch git ... remote or git ... remote get-url origin. When the capability probe exits, these processes may be left behind as suspended orphan git.exe processes.

The recommended fix is to make the capability probe reliably terminate and reap its entire child-process tree, including Git processes, on completion, timeout, or cancellation.