fix(bridge): use os.homedir() for PID file path so Windows stops creating <drive>:\tmp stray folders

[asorry75]

Problem

On Windows, every bridge/daemon start creates a stray folder at the root of whichever drive the process happens to run from.

process.env.HOME is not set on Windows (Windows uses USERPROFILE), so pidFilePath() falls back to "/tmp":

return path.join(process.env.HOME ?? "/tmp", agentHome, "memos-plugin", "daemon", PID_FILENAME);

Node resolves /tmp relative to the current drive root of the process cwd. Concretely:

• daemon started with cwd on C: → writes C:\tmp\.hermes\memos-plugin\daemon\bridge.pid
• daemon started with cwd on D: → writes D:\tmp\.hermes\memos-plugin\daemon\bridge.pid
• install.ps1 uses Start-Process without -WorkingDirectory, so the daemon inherits whatever directory the installer was run from — users who install from D:\ get the PID file on D:\tmp

Two consequences:

1. Stray folders (C:\tmp\.hermes\... and D:\tmp\.hermes\...) appear on drive roots after any bridge/daemon start — confusing, and they accumulate.
2. The singleton guard is broken across entries: the PID file is written to a drive-dependent path, so a daemon started from C: cannot see the PID file written by one started from D: (or vice-versa). killExistingBridge() then fails to kill the previous holder and two daemons fight over the viewer port (observed: two server.started on :18800 from independent processes).

Fix

Use os.homedir() instead of process.env.HOME ?? "/tmp". homedir() is cross-platform: on Windows it returns C:\Users\<user> (via USERPROFILE), on POSIX/macOS it returns the user home. The PID file now always lands at ~/.hermes/memos-plugin/daemon/bridge.pid regardless of cwd or entry point, restoring the singleton guard.

import { homedir } from "node:os";

function pidFilePath(agent: string): string {
  const agentHome = agent === "hermes" ? ".hermes" : ".openclaw";
  return path.join(
    homedir(),
    agentHome,
    "memos-plugin",
    "daemon",
    PID_FILENAME,
  );
}

Verification (Windows 10)

• Before: starting the daemon from C: created C:\tmp\.hermes\memos-plugin\daemon\bridge.pid; from D: created D:\tmp\...; both stale entries pointed to dead PIDs while a third live daemon wrote to yet another location.
• After: daemon writes PID only to C:\Users\<user>\.hermes\memos-plugin\daemon\bridge.pid, matching the actual listener PID. No C:\tmp / D:\tmp folders are created.

Notes

• This is the same Windows-path class of bug as fix: resolve Hermes native memory import path on Windows #2210 (Hermes home resolution) and fix: install.ps1 writes Hermes config template to the wrong location #2211 (install.ps1 runtime home); this one is isolated to the PID file location.
• Related: Bug: admin/restart is self-destructive on Windows (pkill/bash/tsx unavailable, daemon always killed) #2213 (admin/restart self-destructive on Windows) also involves daemon lifecycle on Windows.

[Memtensor-AI]

🤖 Open Code Review

Target: PR #2225
Task: b454687b5703bb12
Base: main
Head: fix/bridge-pid-windows-homedir

✅ OpenCodeReview: No supported files changed.

Generated by cloud-assistant via Open Code Review.

[Memtensor-AI]

⚠️ Automated Test Results: ENV ISSUE

The test environment encountered an issue that requires manual attention.

Details: The contract test phase exited with code 4 and ran zero tests, indicating a test collection/configuration failure rather than an actual test failure related to the diff. [advisory, non-gating] AI-generated tests on branch test/auto-gen-7f8f90a55698ccbd-20260805173543: 22/23 passed, 1 failed — these do NOT affect the PR verdict; review the branch manually.
Branch: fix/bridge-pid-windows-homedir

[Memtensor-AI]

✅ Automated Test Results: PASSED

All tests passed (35/35 executed). memos_local_plugin/unit: 35/35. Duration: 5s [advisory, non-gating] AI-generated tests on branch test/auto-gen-b454687b5703bb12-20260807021221: 41/41 passed — these do NOT affect the PR verdict; review the branch manually.

Branch: fix/bridge-pid-windows-homedir