Isolate the process-manager daemon per home on Windows

[gcsecsey]

Related issues

• Related to AINFRA-2588
• Stacked on Fix Windows E2E hang: bound daemon requests and reap leaked daemon between sessions #4041, this PR removes a distinct leak source.

How AI was used in this PR

Claude cross-referenced the AINFRA-2588 infra investigation with a local reproduction on a Windows machine. It traced the "same-daemon-shared-across-runs" behavior to apps/cli/lib/paths.ts hardcoding the Windows named-pipe names, wrote the fix and a unit test, and verified before/after on Windows (two custom homes share one daemon on trunk vs. two isolated daemons with the fix; the default home still shares a single daemon).

Proposed Changes

The CLI's process-manager daemon is meant to be isolatable per run. Setting STUDIO_PROCESS_MANAGER_HOME gives you your own daemon and sites, which is what the CLI integration-test harness relies on, so tests don't touch each other or a developer's real daemon.

On Windows, that isolation silently did nothing. Unix domain sockets live under the home directory, but Windows named pipes share one flat, machine-global namespace, and the pipe names were hardcoded. So every process on the machine is connected to the same daemon regardless of STUDIO_PROCESS_MANAGER_HOME. As a result, CLI tests (and anything else) on Windows all shared one machine-global daemon: leaked/hung sites from one run bled into the next, and a wedged daemon could poison later runs and other CI jobs on the same agent.

This PR derives the Windows pipe name from the home directory when a custom home is set, so isolation works on Windows the same way it already does on macOS/Linux. The default home keeps its original fixed pipe name, so the shipping desktop app and CLI still share a single daemon exactly as before.

Testing Instructions

• Unit tests: npm test -- apps/cli/tests/paths.test.ts
• Manual (in PowerShell): run two CLI commands with two different STUDIO_PROCESS_MANAGER_HOME values and confirm two separate process-manager-daemon processes now exist. Two invocations with the default home still yield a single shared daemon.

# --- setup ---
npm run cli:build

$cli = "apps\cli\dist\cli\main.mjs"
function Kill-StudioDaemons  { Get-CimInstance Win32_Process | ? { $_.CommandLine -match 'process-manager-daemon\.mjs' } | % { taskkill /F /T /PID $_.ProcessId 2>$null | Out-Null } }
function Count-StudioDaemons { @(Get-CimInstance Win32_Process | ? { $_.CommandLine -match 'process-manager-daemon\.mjs' }).Count }

# --- TEST 1: two custom homes -> two isolated daemons (the fix) ---
Kill-StudioDaemons
$env:STUDIO_PROCESS_MANAGER_HOME = "$env:TEMP\studio-home-A"; node $cli site list | Out-Null
$env:STUDIO_PROCESS_MANAGER_HOME = "$env:TEMP\studio-home-B"; node $cli site list | Out-Null
Start-Sleep -Milliseconds 500
"Isolated daemons: $(Count-StudioDaemons)   (EXPECT 2)"
"home-A logs: $(Test-Path "$env:TEMP\studio-home-A\logs")   home-B logs: $(Test-Path "$env:TEMP\studio-home-B\logs")   (both EXPECT True)"

# --- TEST 2: default home -> one shared daemon (no regression) ---
Remove-Item Env:\STUDIO_PROCESS_MANAGER_HOME
Kill-StudioDaemons
node $cli site list | Out-Null; node $cli site list | Out-Null
Start-Sleep -Milliseconds 500
"Shared daemons (default home): $(Count-StudioDaemons)   (EXPECT 1)"

• CI (stacked): the E2E Tests on windows-x64 job should reach a terminal state well under the 180-minute timeout, with no CAPACITY_LIMIT_REACHED (36/36) cascade in the log.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wpmobilebot]

📊 Performance Test Results

Comparing 7347fd7 vs trunk

app-size

Metric	trunk	7347fd7	Diff	Change
App Size (Mac)	1316.92 MB	1316.83 MB	0.09 MB	⚪ 0.0%

site-editor

Metric	trunk	7347fd7	Diff	Change
load	1066 ms	1056 ms	10 ms	⚪ 0.0%

site-startup

Metric	trunk	7347fd7	Diff	Change
siteCreation	6531 ms	6488 ms	43 ms	⚪ 0.0%
siteStartup	1855 ms	1864 ms	+9 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[bcotrim]

Tested on Windows — pipe isolation works: custom STUDIO_PROCESS_MANAGER_HOME gets its own daemon on a hashed pipe, default home keeps the fixed names.

On suggested fix:
killLeakedDaemonProcesses() taskkills its own cmd.exe wrapper (its command line also contains process-manager-daemon), so the sweep dies mid-loop and can leave daemons alive.

Replicate (Windows):

1. In e2e-helpers.ts, log the swallowed error: catch ( error ) { console.log( '[daemon reap]', error ) }
2. npm run e2e -- app.test.ts
3. Cleanup prints [daemon reap] Error: Command failed: powershell … — suite still reports green.

Fix:

-  "Where-Object { $_.CommandLine -match 'process-manager-daemon' -and $_.ProcessId -ne $PID } | " +
+  "Where-Object { $_.CommandLine -match 'process[-]manager[-]daemon' } | " +

[-] still matches the daemon's command line, but not the sweep's own (which contains the brackets). After the fix, step 2 shows no error and no daemon survives.

[gcsecsey]

Thanks for the review @bcotrim! I'll keep iterating on this to try to pinpoint the root cause on CI, for the time being I'm converting it back to a draft.

[fredrikekelund]

I haven't wrapped my head around these changes just yet, but I wanted to relay what I mentioned elsewhere (see #4075 (comment)): I suggest focusing on landing just the changes that fix the E2E tests first, and pursuing this PR as a follow-up. These changes aren't strictly needed to fix the E2E tests, and landing them as part of that work might add confusion.