🪟 Windows Canary: combined build/test of all open Windows fixes

[thedotmack]

🪟 Windows Canary — combined build/test branch for all open Windows fixes

We have a large cluster of open Windows PRs that each fix a different piece of the same cross-platform story (spawn, hooks, chroma, mcp launcher, supervisor, settings, runtime deps). They overlap heavily — several touch the same launcher strings and the same ChromaMcpManager spawn path — so merging them one-by-one keeps re-introducing conflicts and nobody can see them working together.

This branch bundles them into one canary so we can validate the combined result.

⚠️ Calling all Windows contributors

@CaTeIM @ousamabenyounes @sabinss4 @YOMXXX @alessandropcostabr @Bruce583102198 @PulseCheckAI — your Windows PRs are bundled here.

I (@thedotmack) do not have a Windows machine, so I genuinely cannot test this myself — we have to work this one out together. Please:

1. git fetch origin && git checkout windows-canary
2. npm ci (or bun install) then npm run build
3. Install/point Claude Code at this build and exercise it on real Windows (PowerShell, Git Bash, and cmd.exe if you can)
4. Report back in this thread: ✅ works / ❌ broke, with the shell + Windows version. Screenshots/logs of any console-window flashes, MCP error -32000, EPIPE, or path-resolution failures are gold.

If your fix needed adjustment to combine with the others (see "Conflict decisions" below), please confirm the resolution still solves your original issue.

---

✅ PRs bundled in this canary (12)

PR	Author	What it fixes
#2208	@thedotmack	Restore Windows spawn (PR #751 re-apply) + Windows CI
#2489	@CaTeIM	Launch mcp-search via node so Windows can spawn it
#2502	@ousamabenyounes	Drop cmd.exe wrap on Windows uvx spawn (chroma)
#2507	@sabinss4	Add PowerShell call operator (&) to hook commands
#2593	@YOMXXX	Escape cmd.exe metacharacters in uvx args
#2594	@YOMXXX	Replace sh launcher with cross-platform node -e (#2461)
#2598	@YOMXXX	Replace fragile $SHELL -lc PATH probe with printenv-first
#2599	@YOMXXX	Make Windows captureProcessStartToken actually return a token (#2578)
#2636	@alessandropcostabr	Strip BOM from settings.json + lifecycle stdin-guard exemption
#2654	@Bruce583102198	Suppress printf write errors when pipe breaks in inline bash hooks
#2658	@CaTeIM	Restore plugin runtime deps after auto-upgrade
#2668	@PulseCheckAI	Spawn uvx directly on Windows instead of via cmd.exe (#2667)

🔀 Conflict decisions (please sanity-check these)

These PRs proposed competing approaches to the same problem — only one can be active at a time. Here's what the canary currently uses and what got superseded:

• Chroma uvx spawn — three PRs, two approaches:
  • fix(chroma): drop cmd.exe wrap on Windows uvx spawn (2426) #2502 + fix(chroma): spawn uvx directly on Windows instead of via cmd.exe (closes #2667) #2668 agree: spawn uvx directly (no cmd.exe wrap). ← canary uses this.
  • fix(chroma): escape cmd.exe metacharacters in uvx args on Windows #2593 keeps the cmd.exe wrap but escapes metacharacters (^<>&|, %%). Merged as a no-op since direct-spawn makes the wrap unnecessary. @YOMXXX — if direct-spawn doesn't work on your Windows setup, this is the fallback; please test.
• mcp-search launcher — both node-based:
  • fix(mcp): replace sh launcher with cross-platform node -e (closes #2461) #2594 spawns a subprocess with signal-forwarding. ← canary uses this (closes Fix Windows compatibility: replace sh spawn + silence printf EPIPE #2461, kept fix(mcp): launch mcp-search via node so Windows can spawn it #2489's distribution test green).
  • fix(mcp): launch mcp-search via node so Windows can spawn it #2489 loads mcp-server.cjs in-process via require (superseded, but fix(mcp): launch mcp-search via node so Windows can spawn it #2489 still contributes the node move + its test).
• Hook PATH probe — fix(hooks): replace fragile $SHELL -lc PATH probe with printenv-first pattern #2598's printenv-first probe + fix: suppress printf write errors when pipe breaks in inline bash hooks #2654's 2>/dev/null pipe-suppression are combined (complementary).

🚫 Deliberately excluded (need a rebase or a decision)

• fix: Codex transcript ingestion + queue self-deadlock on Windows (closes #2192) #2209 (@thedotmack) — Codex transcript + queue self-deadlock. The watcher.ts half (Windows transcript-append fix) is clean, but the SessionRoutes.ts half collides with main's since-merged handleGeneratorExit / GeneratorExitHandler refactor. The [Bug] Codex transcript ingestion on Windows finds no/late items and can strand pending observations #2192 in-flight-requeue fix is not present in the new handler and must be re-ported there. Needs a rebase onto main before it can join.
• fix: replace printf '%s\n' with echo in hook path-finding subshells (2439) #2501 (@ousamabenyounes) — echo instead of printf '%s\n' in hook subshells (Windows (Git Bash): printf write error Permission denied blocks UserPromptSubmit hook #2439). Superseded by fix(hooks): replace fragile $SHELL -lc PATH probe with printenv-first pattern #2598's printenv-first probe already in the canary; its tests assert the old launcher format. If printf '%s\n' genuinely misbehaves on your shell, please say so — that would override fix(hooks): replace fragile $SHELL -lc PATH probe with printenv-first pattern #2598.
• fix(hooks): silence Windows Git Bash EPIPE/EACCES on plugin-path resolver #2526 (@ajs-uk-dev) — Silence Windows Git Bash EPIPE/EACCES on the path resolver. Functionally covered by fix: suppress printf write errors when pipe breaks in inline bash hooks #2654's 2>/dev/null pipe-suppression already in the canary. Please confirm fix: suppress printf write errors when pipe breaks in inline bash hooks #2654 fully resolves your case, or what's still leaking.
• Windows: replace bash hooks with PowerShell to eliminate visible console windows #2476 (draft) — PowerShell-hook rewrite. A competing architecture to the bash-hook fixes here; left out as a draft.
• Add Codex ingestion provider and Windows Chroma launch fix #2614 (draft) — Codex ingestion + Windows chroma; draft, overlaps the chroma trio.

🧪 Verification done locally (macOS — Windows still needs you)

• npm run build ✅ all bundles regenerate from merged source
• tsc --noEmit: 24 errors — identical to origin/main; 0 introduced by this merge (the pre-existing TS baseline is fixed by Fix upstream TypeScript baseline #2511)
• bun test: 54 failures — identical to origin/main; 0 introduced by this merge (pre-existing test baseline is fixed by Fix upstream test baseline regressions #2512)
• Windows/chroma/infra suites that this branch touches (tests/infrastructure, tests/services/sync): 186 pass / 0 fail

In other words: this branch adds the Windows fixes without regressing the baseline. The remaining red is pre-existing and owned by #2511/#2512.

Notes

• Diffstat: 20 files, +1,572 / −606 (incl. regenerated bundles).
• This is a canary, not a merge target — once Windows folks confirm what works, we'll land the validated fixes via their individual PRs (or fast-track them).
• CHANGELOG.md intentionally not touched (auto-generated).

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This canary PR bundles 12 Windows-compatibility fixes into one combined branch for collective testing before individual merges: it replaces the sh -c MCP launcher with a cross-platform node -e launcher, removes the cmd.exe /c uvx wrapper in ChromaMcpManager, adds PowerShell & call operator support in Windsurf/Gemini hook installers, implements a printenv-first PATH probe, strips UTF-8 BOM from settings.json, and fixes Windows captureProcessStartToken PID-reuse detection.

• MCP launcher (plugin/.mcp.json): replaced a Bash sh -c inline script with a node -e inline JavaScript launcher that performs the same plugin-root search and spawns mcp-server.cjs with signal forwarding — eliminating the sh dependency on Windows.
• ChromaMcpManager: dropped the Windows-only cmd.exe /c uvx … wrapper; uvx is now spawned directly on all platforms, preventing >= and < in --with arguments from being misinterpreted as I/O redirection by cmd.exe.
• ProcessManager.ts: DATA_DIR / PID_FILE constants are now hardcoded to path.join(homedir(), '.claude-mem'), diverging from the paths.dataDir() / paths.workerPid() helpers that honour the CLAUDE_MEM_DATA_DIR env-var and settings-file override.

Confidence Score: 3/5

The ChromaMcpManager, BOM stripping, and captureProcessStartToken changes look correct and well-tested, but the DATA_DIR hardcoding in ProcessManager.ts will silently misdirect PID file and migration-marker writes for any user who has configured CLAUDE_MEM_DATA_DIR, causing the worker health check to permanently report the worker as dead on those setups.

The MCP launcher rewrite and uvx direct-spawn are well-reasoned and the new test coverage for the Windows spawn path is solid. ProcessManager.ts no longer calls paths.dataDir(), which in the original code read CLAUDE_MEM_DATA_DIR from the environment and settings file before falling back to ~/.claude-mem — the hardcoded replacement creates a split that makes the daemon appear dead for users with non-default data directories. The PowerShell & operator in the hooks installers is also applied unconditionally by OS rather than by the shell the target tool actually uses, which could break Windows Gemini CLI or Windsurf users who invoke hooks outside PowerShell.

src/services/infrastructure/ProcessManager.ts (DATA_DIR hardcoding) and src/services/integrations/WindsurfHooksInstaller.ts + GeminiCliHooksInstaller.ts (unconditional PowerShell call operator)

Important Files Changed

Filename	Overview
src/services/infrastructure/ProcessManager.ts	DATA_DIR hardcoded to ~/.claude-mem, dropping paths.dataDir() which honours CLAUDE_MEM_DATA_DIR; PID file, migration markers, and DB-backup paths will go to the wrong location for users with a custom data directory.
src/services/sync/ChromaMcpManager.ts	Drops Windows cmd.exe/c uvx wrapper — direct uvx spawn on all platforms prevents redirection misparse of --with version specifiers; POSIX tree-kill logic added for orphan cleanup.
plugin/.mcp.json	MCP launcher replaced from sh -c to node -e inline JS; cross-platform plugin-root search with signal forwarding to child process; removes sh dependency on Windows.
src/shared/SettingsDefaultsManager.ts	BOM stripping added before JSON.parse to handle Windows-tool-generated settings.json files; correct and non-breaking.
src/supervisor/process-registry.ts	Windows captureProcessStartToken now queries PowerShell Get-Process for StartTime.Ticks
src/services/integrations/WindsurfHooksInstaller.ts	Adds PowerShell & call operator prefix on win32; correct for PowerShell hook execution but would break cmd.exe invocation if Windsurf uses that shell on Windows.
src/services/integrations/GeminiCliHooksInstaller.ts	Same PowerShell & operator added as WindsurfHooksInstaller; same caveat applies — only safe if Gemini CLI always invokes hooks via PowerShell on Windows.
plugin/hooks/hooks.json	PATH probe changed to printenv-first with $SHELL -lc fallback; reduces shell startup overhead and works on shells that don't support -lc flag.
tests/services/sync/chroma-mcp-manager-windows-spawn.test.ts	New Windows spawn regression test verifying uvx is spawned directly without cmd.exe wrapper and version specifiers survive as argv elements.
tests/infrastructure/plugin-distribution.test.ts	Updated to assert node-based MCP startup command contains expected JS content (CLAUDE_CONFIG_DIR, plugin root paths, mcp-server.cjs); passes against new .mcp.json.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Claude Code spawns MCP server] --> B["node -e inline-JS launcher"]
    B --> C{Search plugin root candidates}
    C -->|Found| D["spawn mcp-server.cjs with stdio inherit"]
    C -->|Not found| E["stderr error + exit 1"]
    D --> F[Forward SIGTERM SIGINT SIGHUP to child]
    D --> G{Child exits}
    G -->|signal| H["re-raise signal on self"]
    G -->|code| I["process.exit(code)"]

    subgraph ChromaMcpManager spawn path
        J["connectInternal()"] --> K["spawn uvx directly on all platforms"]
        K --> L["argv: --with onnxruntime>=1.20 --with protobuf<7"]
        L --> M["No cmd.exe redirection misparse"]
    end

    subgraph DATA_DIR regression
        N["paths.dataDir() - honours CLAUDE_MEM_DATA_DIR"] -.removed.-> O["Hardcoded ~/.claude-mem"]
        O --> P["PID file + migration markers go to wrong path for custom data dirs"]
    end

Loading

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
src/services/infrastructure/ProcessManager.ts:23-25
**DATA_DIR hardcoding drops custom-data-directory support**

`paths.dataDir()` (previously used here) reads `CLAUDE_MEM_DATA_DIR` from the environment first, then falls back to a value from `settings.json`, then falls back to `~/.claude-mem`. The replacement hardcodes only the last fallback. Any user who has set `CLAUDE_MEM_DATA_DIR` (via env var or `settings.json`) will now have their PID file, migration marker files, and DB backup paths silently written to `~/.claude-mem` instead of the configured directory. The practical effect is that `validateWorkerPidFile` reads from a path that the worker never writes to, so the worker appears perpetually dead and the caller may spawn duplicate instances or refuse to start.

### Issue 2 of 3
src/services/integrations/WindsurfHooksInstaller.ts:144-145
**`& ` call operator assumes PowerShell; breaks cmd.exe invocation**

The `& ` prefix is PowerShell-specific: it is the call operator required to invoke a quoted executable path as a command in PowerShell. If Windsurf (or Gemini CLI in the parallel change) executes hook commands via `cmd.exe` instead of PowerShell on Windows, the leading `& ` will be interpreted as a command separator in `cmd.exe` and the hook will fail silently. The condition `process.platform === 'win32'` is applied at install time without checking which shell the target tool actually uses to invoke hooks. Confirm that Windsurf and Gemini CLI always route hook commands through PowerShell on Windows before treating this as unconditionally safe.

### Issue 3 of 3
plugin/.mcp.json:8
**MCP launcher exit sentinel 128 on Windows signal re-raise failure**

The launcher forwards `SIGTERM`, `SIGINT`, and `SIGHUP` to the child. The exit handler calls `process.kill(process.pid, sig)` when the child exits due to a signal. If this throws on Windows (where many POSIX signals are unsupported), the catch branch calls `process.exit(128)` — a non-zero, non-standard exit code. Callers that check the launcher's exit code for success/failure may misinterpret 128 as an error, even though the child itself may have exited cleanly.

_{Reviews (1): Last reviewed commit: "build: regenerate bundles from merged Wi..." | Re-trigger Greptile}

[greptile-apps]

DATA_DIR hardcoding drops custom-data-directory support

paths.dataDir() (previously used here) reads CLAUDE_MEM_DATA_DIR from the environment first, then falls back to a value from settings.json, then falls back to ~/.claude-mem. The replacement hardcodes only the last fallback. Any user who has set CLAUDE_MEM_DATA_DIR (via env var or settings.json) will now have their PID file, migration marker files, and DB backup paths silently written to ~/.claude-mem instead of the configured directory. The practical effect is that validateWorkerPidFile reads from a path that the worker never writes to, so the worker appears perpetually dead and the caller may spawn duplicate instances or refuse to start.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/services/infrastructure/ProcessManager.ts
Line: 23-25

Comment:
**DATA_DIR hardcoding drops custom-data-directory support**

`paths.dataDir()` (previously used here) reads `CLAUDE_MEM_DATA_DIR` from the environment first, then falls back to a value from `settings.json`, then falls back to `~/.claude-mem`. The replacement hardcodes only the last fallback. Any user who has set `CLAUDE_MEM_DATA_DIR` (via env var or `settings.json`) will now have their PID file, migration marker files, and DB backup paths silently written to `~/.claude-mem` instead of the configured directory. The practical effect is that `validateWorkerPidFile` reads from a path that the worker never writes to, so the worker appears perpetually dead and the caller may spawn duplicate instances or refuse to start.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

& call operator assumes PowerShell; breaks cmd.exe invocation

The & prefix is PowerShell-specific: it is the call operator required to invoke a quoted executable path as a command in PowerShell. If Windsurf (or Gemini CLI in the parallel change) executes hook commands via cmd.exe instead of PowerShell on Windows, the leading & will be interpreted as a command separator in cmd.exe and the hook will fail silently. The condition process.platform === 'win32' is applied at install time without checking which shell the target tool actually uses to invoke hooks. Confirm that Windsurf and Gemini CLI always route hook commands through PowerShell on Windows before treating this as unconditionally safe.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/services/integrations/WindsurfHooksInstaller.ts
Line: 144-145

Comment:
**`& ` call operator assumes PowerShell; breaks cmd.exe invocation**

The `& ` prefix is PowerShell-specific: it is the call operator required to invoke a quoted executable path as a command in PowerShell. If Windsurf (or Gemini CLI in the parallel change) executes hook commands via `cmd.exe` instead of PowerShell on Windows, the leading `& ` will be interpreted as a command separator in `cmd.exe` and the hook will fail silently. The condition `process.platform === 'win32'` is applied at install time without checking which shell the target tool actually uses to invoke hooks. Confirm that Windsurf and Gemini CLI always route hook commands through PowerShell on Windows before treating this as unconditionally safe.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

MCP launcher exit sentinel 128 on Windows signal re-raise failure

The launcher forwards SIGTERM, SIGINT, and SIGHUP to the child. The exit handler calls process.kill(process.pid, sig) when the child exits due to a signal. If this throws on Windows (where many POSIX signals are unsupported), the catch branch calls process.exit(128) — a non-zero, non-standard exit code. Callers that check the launcher's exit code for success/failure may misinterpret 128 as an error, even though the child itself may have exited cleanly.

Prompt To Fix With AI

This is a comment left during a code review.
Path: plugin/.mcp.json
Line: 8

Comment:
**MCP launcher exit sentinel 128 on Windows signal re-raise failure**

The launcher forwards `SIGTERM`, `SIGINT`, and `SIGHUP` to the child. The exit handler calls `process.kill(process.pid, sig)` when the child exits due to a signal. If this throws on Windows (where many POSIX signals are unsupported), the catch branch calls `process.exit(128)` — a non-zero, non-standard exit code. Callers that check the launcher's exit code for success/failure may misinterpret 128 as an error, even though the child itself may have exited cleanly.

How can I resolve this? If you propose a fix, please make it concise.

[YOMXXX]

Hi @thedotmack — thanks for bundling these together, the canary approach makes a lot of sense given the overlap.

My PRs in the canary

#2593 (cmd.exe metachar escaping) — agree that direct-spawn (#2502/#2668) is the better path. Happy for #2593 to sit as a no-op fallback; if direct-spawn works across environments, we can close it.

#2594 (node -e MCP launcher) — glad this was picked as the launcher approach. One note on Greptile's Issue 3 below.

#2598 (printenv-first PATH probe) — also just pushed a follow-up fix (e060a674) removing tr ' ' ':' which was corrupting Windows paths containing spaces (e.g. /c/Program Files/nodejs). That fix should probably be pulled into the canary as well.

#2599 (Windows captureProcessStartToken) — straightforward, no concerns.

On the Greptile issues

Issue 1 (DATA_DIR hardcoding in ProcessManager.ts) — this looks like a real regression. paths.dataDir() honours CLAUDE_MEM_DATA_DIR from env/settings, so hardcoding ~/.claude-mem would silently break multi-profile setups. Probably worth restoring paths.dataDir() here.

Issue 2 (PowerShell & call operator) — this came from #2507. The concern is valid: & is PowerShell-specific and would break under cmd.exe. Worth confirming with @sabinss4 which shell Windsurf/Gemini CLI actually use for hook invocation on Windows.

Issue 3 (exit code 128 on Windows signal re-raise) — from my #2594. The process.exit(128) fallback only fires when process.kill(pid, sig) throws (Windows doesn't support most POSIX signals). I can change this to process.exit(0) since the child already exited — the launcher's job is done at that point. Will push a fix.

Happy to help address Issues 1 and 3 if that would be useful — just let me know.

[bigmanBass666]

Windows test report (posted via Claude Code agent on behalf of @bigmanBass666)

Environment:

• Windows 11 Home China (22631)
• Shell: Git Bash (MSYS2), PowerShell 5.1
• claude-mem version: 13.3.0 (from installed_plugins.json)
• Worker: 12.1.0 (stale, not yet restarted after upgrade)

Issue reproduced:

• mcp-search MCP server fails to start — MCP error -32000
• .mcp.json in 13.3.0 uses "command": "sh" with a pipe-based path resolver
• Reproducing the exact sh -c command in Git Bash produces: printf: write error: Permission denied
• Root cause: { producer; } | while read ... break; done — when consumer breaks early, remaining printf calls get EACCES on Windows MSYS emulated pipes (silent SIGPIPE on Linux/macOS)

Workaround confirmed working:
Patched 13.3.0/.mcp.json to use direct node invocation (same as 12.1.0):

{
  "mcpServers": {
    "mcp-search": {
      "type": "stdio",
      "command": "node",
      "args": ["${CLAUDE_PLUGIN_ROOT}/scripts/mcp-server.cjs"]
    }
  }
}

MCP server starts successfully after this change. Worker health endpoint at localhost:37777/api/health responds normally.

This confirms PR #2489's approach is correct. The sh launcher is fundamentally broken on Windows due to MSYS pipe emulation behavior. Using node directly bypasses the entire issue.

Note: The worker was still running 12.1.0 at test time (pre-restart). After a full Claude Code restart the SessionStart hook should bring up the 13.3.0 worker. The .mcp.json patch will need to be re-applied after each plugin auto-update until the canary lands.

✅ node-based launcher works
❌ sh -c pipe resolver fails on Windows (EACCES)

[CaTeIM]

✅ Windows test report — @CaTeIM

Environment: Windows 11 Pro 10.0.28000 · node v24.15.0 · bun 1.3.14 · uvx at ~/.local/bin/uvx
Shells exercised: PowerShell 7, Git Bash, cmd.exe (limited — see notes)

Setup

git checkout windows-canary → npm ci → npm run build → all clean, no errors.

End-to-end checks

Area	Result	Detail
mcp-search launcher (PR #2594, supersedes my #2489)	✅	node -e bootstrap spawns mcp-server.cjs via child_process.spawn(process.execPath, …, {stdio:'inherit'}) with SIGTERM/INT/HUP forwarding. Real initialize handshake from PowerShell with UseShellExecute=false (same path Claude Code uses) returns proper serverInfo for claude-mem 13.3.0. Confirms the "Connection closed" failure from my #2489 is still resolved by #2594's approach.
Plugin runtime deps (my #2658 Fix A)	✅	plugin/package.json still declares ajv ^8.20.0 + ajv-formats ^3.0.1. Build guardrail preserved.
Auto-install on upgrade (my #2658 Fix B)	✅	ensureRuntimeDeps() in version-check.js tested across all three paths: broken (spawns detached bun install, marker written in the version root per the Greptile review fix, log opened), cooldown (second call within 10 min no-ops), healthy (node_modules present → no-op).
Chroma uvx direct-spawn (PR #2502/#2668)	✅	tests/services/sync/chroma-mcp-manager-windows-spawn.test.ts "spawns uvx directly on Windows (no cmd.exe /c wrapper)" passes (2/2 on canary; fails on main).

Test suite (tests/infrastructure + tests/services/sync)

Canary on Windows: 163 pass / 15 fail / 8 skip (12 unique failing test names after dedup) vs main on Windows: 165 pass / 13 fail / 8 skip (12 unique).

Name-only diff vs main (timings stripped):

• Canary fixes 1 test: ChromaMcpManager Windows spawn (2426) > spawns uvx directly on Windows (no cmd.exe /c wrapper) ✅
• Canary introduces 1 failure: ProcessManager > captureProcessStartToken > returns null on win32 (liveness-only fallback path) ⚠️ — this test (tests/infrastructure/process-manager.test.ts:384) forces process.platform = 'win32' and asserts captureProcessStartToken(pid) returns null. PR fix(supervisor): make Windows captureProcessStartToken actually return a token (closes #2578) #2599 (@YOMXXX) changes this function to actually return a real token on win32, which makes the assertion fail. The test needs to be updated or removed alongside fix(supervisor): make Windows captureProcessStartToken actually return a token (closes #2578) #2599 — the parenthetical "(liveness-only fallback path)" described the OLD pre-fix(supervisor): make Windows captureProcessStartToken actually return a token (closes #2578) #2599 behavior.
• 11 common failures (same on canary and main on Windows) = pre-existing Windows baseline unrelated to this merge: runOneTimeV12_4_3Cleanup (4), HealthMonitor isPortInUse / waitForPortFree (4), ProcessManager.resolveWorkerRuntimePath, ChromaMcpManager singleton (2). The maintainer doesn't see these on macOS; they look like Windows-specific test plumbing issues (port reuse semantics, Windows process trees, file-locking during cleanup), not regressions from this canary.

Live evidence for #2654 / #2526 (EPIPE suppression)

Independent of the canary, my running Claude Code session — using the currently-installed (not canary) plugin — is generating the following on every PostToolUse observation hook right now:

/usr/bin/bash: line 1: printf: write error: Permission denied

This is exactly the EPIPE/EACCES leakage that #2654 suppresses with 2>/dev/null and that #2526 also targets. Strong real-world signal that these belong in the canary as-is.

Live deploy

After the isolated checks above, I pointed my Claude Code at the canary by copying the built plugin/ contents into the active plugin cache at ~/.claude/plugins/cache/thedotmack/claude-mem/13.3.0/ (the dir Claude Code actually reads — not the marketplace clone; that was the bit that tripped me up in #2489's earlier sessions). After the worker restart:

• claude mcp list shows plugin:claude-mem:mcp-search as node -e <#2594 bootstrap with c.spawn + signal forwarding> — ✓ Connected.
• Worker healthy on http://127.0.0.1:37777.
• MCP initialize handshake against the cache's mcp-server.cjs returns proper serverInfo.

To pick this up in my live GUI session I'll do a full Claude Code restart.

Notes

• cmd.exe shell test was inconclusive — my repro had quoting issues with paths containing spaces ("Google Drive"). PowerShell's UseShellExecute=false path is what Claude Code actually uses, so this is more representative than cmd.exe anyway.
• I'm happy to re-run any specific shell scenario or attach raw logs — ping me.

🤖 Generated with Claude Code

[CaTeIM]

Follow-up after live restart — confirming #2654 in production: after switching my Claude Code session to the canary plugin (cache 13.3.0 deployed + restart), my PostToolUse observation hook no longer emits printf: write error: Permission denied. Same machine, same Git Bash, same hook flow — the only thing that changed is the bundled hook now suppresses the broken pipe with 2>/dev/null. Before the restart, every Bash tool call in this very session was producing the EPIPE; after the restart, zero occurrences across many subsequent calls.

cc @Bruce583102198 — your fix is doing exactly what it claims.

[alessandropcostabr]

Windows 11 Home SL 26200 — full triple-shell report (@alessandropcostabr)

Environment: Windows 11 Home SL 10.0.26200.8457 · node v24.11.1 · bun 1.3.14 · git 2.53 · Claude Code 2.1.145

Deploy

Plugin marketplaces/thedotmack/plugin/ replaced byte-for-byte by canary bcf437fb's pre-built plugin/ (md5 C7C58737..., 4,031,405 bytes). bun install ran clean (706 packages); npm run build fails on @better-auth/kysely-adapter ↔ kysely drift — irrelevant since the canary commit already ships regenerated bundles. Backup kept at plugin.bak-pre-canary-... (md5 744A9AB5..., the previous 23/05 build).

Discriminator counts in the deployed bundle

Marker	Count	Source
/api/context/inject (canary client path)	7	—
/v1/context/inject (legacy)	0	(intentionally removed)
isTTY stdin guard	1	#2188
SessionStart lifecycle exempt	1	#2636
node -e MCP launcher (.mcp.json)	✅	#2594
BOM strip in SettingsDefaultsManager	present	#2636
@better-auth/api-key (x-api-key default)	1	(see note below)

Per-shell results

Shell	claude mcp list	Live tool calls	printf write error	MCP error -32000	Console flash
PowerShell 7	claude-mem ✓ Connected (+ 6 others)	observations STORED (obsId 34634)	0	0	none
Git Bash (MSYS)	claude-mem ✓ Connected	session registered, tool calls captured	0 (confirms #2654)	0	none
cmd.exe (interactive)	claude-mem ✓ Connected (all 7 servers)	claude --version → 2.1.145	0	0	none

Live capture E2E

Worker uptime 30+ min post-restart, 0 ERROR / 0 FATAL / 0 server-beta-fallback in the 74-line log. Pipeline notebook → CF → Mach10 → Express → BullMQ → Redis → Qdrant flowing: 68 events / 10 min acknowledged server-side, with observations generated downstream.

Worker invocation:

"C:\Users\aless\.bun\bin\bun.exe" C:\Users\aless\.claude\plugins\marketplaces\thedotmack\plugin\scripts\worker-service.cjs --daemon

Bonus — Codex CLI MCP integration confirmed

Wired [mcp_servers.claude-mem] into ~/.codex/config.toml pointing at the same mcp-server.cjs (via node direct, mirroring the .mcp.json durable-fix pattern). Inside codex REPL, /mcp lists claude-mem alongside native codex_apps with all 21 tools available (search, smart_search, memory_add, observation_search, timeline, etc.). Auth: Unsupported is expected for stdio-local MCP servers — not a defect. Codex capture hooks (Peça 2) still pending — .codex-plugin/ in the bundle only ships plugin.json without handlers, so Codex sessions can read the claude-mem corpus but won't generate observations of their own yet.

Non-blocking note for maintainers running server-beta behind a proxy

The deployed client bundle uses X-Api-Key on POST /v1/events (the @better-auth/api-key default). The server-beta middleware in src/server/middleware/{auth,postgres-auth}.ts only reads Authorization: Bearer. Anyone running server-beta behind a header-normalizing proxy (Cloudflare → Express in my case) gets 401 {"error":"Unauthorized","message":"Missing bearer API key"} even with a valid key. Direct-LAN setups don't hit it because no proxy is in the path.

I opened #2719 to make the server middleware accept X-Api-Key as fallback to Bearer — fully backward-compatible (Bearer remains canonical and wins when both are sent), 3 new unit tests passing alongside the existing 12 in tests/server/auth-api-key.test.ts, verified end-to-end against my deployment.

Net result

Canary bcf437fb is green across all three Windows shells for me. Zero changes outside the deployed bundle, backup retained for instant rollback if needed.

cc @thedotmack @CaTeIM @YOMXXX @Bruce583102198

🤖 Generated with Claude Code

[tomeyerman]

Independent Windows validation: #2806 fixed the PATH gap, but the cmd.exe quoting defect this PR targets still breaks semantic search on a clean v13.4.0 / latest main.

Flagging this so closing #2790 isn't read as "Windows Chroma fixed" — there are two distinct root causes here:

• fix(chroma): put uv's bin dir on the chroma-mcp child PATH (part of #2790) #2806 (the PATH fix) is correct and necessary — it ensures uvx is resolvable on the chroma-mcp child PATH.
• It is not sufficient. The spawn in connectInternal on main is unchanged — it still does ['/c', 'uvx', ...commandArgs.map(quoteForCmdExe)], so cmd.exe parses the >/< in the dep pins as redirection operators before uvx ever runs. The quoteForCmdExe helper added in v13.4.0 (Clear defect backlog: plans 01–11 + standalone fixes (suite 46→0 fail, typecheck 24→0) #2701) does not survive Node's shell:false re-quoting.

Minimal repro on Windows 11, claude-mem 13.4.0, uvx 0.9.11, Python 3.13.9, with uvx confirmed on PATH (i.e. this is post-#2806 behavior — the PATH precondition is already satisfied, which isolates the failure to the >/< quoting, not PATH):

(A) Direct spawn — exactly what this PR does — WORKS:

uvx --python 3.13 --with "onnxruntime>=1.20" --with "protobuf<7" chroma-mcp==0.2.6 --client-type persistent --data-dir <dir>
  → {"result":{ ... "serverInfo":{"name":"chroma","version":"1.6.0"}}}    (boots, waits for stdio)

(B) cmd.exe /c uvx — what main's connectInternal still does — FAILS in ~270ms:

cmd /c uvx --python 3.13 --with onnxruntime>=1.20 --with protobuf<7 chroma-mcp==0.2.6 --client-type persistent --data-dir <dir>
  → "The system cannot find the file specified"    (cmd parses <7 as stdin redirection from a file named "7")

Same args, same machine — the only difference is the cmd.exe wrapper, and it dies in ~270 ms on the redirection.

So this PR (drop the cmd.exe wrapper, spawn uvx directly) is the actual fix for the quoting defect, and #2806 is the complementary PATH half. With #2806 now merged, the PATH confound is gone, so this is the remaining blocker for Windows semantic search. The corresponding issues (#2716, #2667) are currently closed as not planned despite the defect still reproducing on latest main.

Happy to check out this branch, build it, and confirm Chroma connects end-to-end on Windows 11 if that helps land it.

[rodboev]

One more Windows rollup note from the newer follow-up wave: there are a few additional open Windows-focused PRs now that may be worth tracking alongside this canary if you do another bundle or maintainer pass:

• fix: install Windows Claude Code hooks without bash #2945 fix: install Windows Claude Code hooks without bash ([Windows] Hook execution flashes black console window on every tool use #2869). This is the broader issue-closing slice and effectively supersedes the narrower Bun-popup-only PR fix(windows): suppress console window flash in findBun() spawnSync call (closes #2869) #2890.
• fix(windows): carry windowsHide through the remaining live Windows spawn paths (closes #2900) #2921 fix(windows): carry windowsHide through the remaining live Windows spawn paths ([Windows] git subprocess calls in worker-service.cjs lack windowsHide -> console windows flash constantly #2900).
• fix(setup): restore tree-sitter CLI on clean Windows installs (closes #2910) #2918 fix(setup): restore tree-sitter CLI on clean Windows installs (v13.5.6: smart_search/smart_outline/smart_unfold return 0 symbols on clean Windows install - tree-sitter-cli binary never downloaded (--ignore-scripts), #1247's extensionless existsSync check still unfixed #2910).
• fix(context): avoid blocking Claude SessionStart on Windows cold boot (closes #2903) #2917 fix(context): avoid blocking Claude SessionStart on Windows cold boot ([Windows] VS Code extension's 60s init deadline exceeded by claude-mem's slow worker cold-boot — extension unusable (terminal works) #2903).
• fix(windows): suppress console window flash in findBun() spawnSync call (closes #2869) #2890 fix(windows): suppress console window flash in findBun() if you still want to keep the narrow predecessor visible separately, though fix: install Windows Claude Code hooks without bash #2945 absorbs that piece.

For #2945 specifically: the Linux/macOS-facing jobs are green on the current head, and the only remaining red check is the same Windows npm-install/node-gyp Visual Studio toolchain failure already showing up on other open Windows PRs rather than a new branch-specific regression.