[umbrella] Windows / Git Bash client integration support

[pizofreude]

I'm running daimon-memory's server in Docker Desktop on Windows (Linux containers via WSL2) and the clients (Claude Code, Codex, Hermes) from Git Bash. The server-side path is clean — docker compose up works on Windows out of the box. The three client install scripts, however, have POSIX assumptions that don't survive Git Bash for Windows.

Blocker 1: integrations/codex/install.sh

• Lines 90–92: sed -i.bak is used three times to substitute __DAIMON_PLUGIN_ROOT__, __DAIMON_MCP_URL__, and __DAIMON_API_KEY__ in staged plugin files. MSYS sed (Git Bash) handles -i.bak differently than GNU sed and can produce stray .bak files in the plugin directory or mangle paths with backslashes.
• Lines 43, 98: command -v python3 and a heredoc Python patcher. python3 is not in Git Bash's default PATH on Windows. The installer silently skips enabling Codex native memory, leaving the mirror broken (the warning is just a soft return-1).

The same file already uses Python for config.toml patching, so Python is already a known dependency — the rest of the script just needs to follow suit.

Blocker 2: integrations/hermes/install.sh

• Uses POSIX sed to edit $HERMES_HOME/config.yaml. If a user has previously edited that file on Windows (CRLF), the sed line injection produces mixed line endings that yaml.safe_load rejects on next read.

Blocker 3: integrations/claude-code/plugins/daimon-memory/scripts/

• recall-state.mjs:11, nudge-lib.mjs:57, precompact-state.mjs:13: state directory falls back to homedir() + ".local/state" when XDG_STATE_HOME is unset. On Windows this is C:\Users\<user>\.local\state\... — functional but non-idiomatic. %LOCALAPPDATA%\daimon-memory\... would be the Windows-correct path.

Acceptance criteria

• All three install scripts either use Python (with a py -3 fallback) or portable shell that survives Git Bash.
• A Windows + Git Bash + Docker Desktop smoke test is documented in README.md (analogous to the existing "Quick start" section).
• Per-script Windows path handling: prefer %LOCALAPPDATA% (Windows) / ~/.local/state (POSIX).
• The cross-client parity test at integrations/tests/nudge-lib.test.mjs continues to pass.

Why this matters

The README's headline claim is "One backend for Claude Code, Codex, Hermes, and your own agents." A Windows + Git Bash user is a real second user — without this fix, the Codex and Hermes clients are effectively Linux/macOS-only.

Related sub-issues I'd like to land before this umbrella can close:

• Codex sed -i.bak → Python rewrite
• Claude Code state path: prefer %LOCALAPPDATA% on Windows
• Hermes sed on YAML → Python rewrite
• Promote the XDG_STATE_HOME fallback helper to lib/state-paths.mjs and share it across Claude and Codex

[wakbijok]

Thank you so much for this — the whole batch is genuinely one of the best issue reports I've received, file/line refs and patches included. You're the project's first external adopter, so I want to get this right.

Status:

• The Git Bash compat group is now merged to main via fix(integrations): Windows / Git Bash client support (tier-2) #13 (built largely on your proposed patches): the Codex installer substitutes placeholders via Python with a py -3 fallback (integrations/codex: replace sed -i.bak with python (Windows + Git Bash compat) #3), and client state now resolves to %LOCALAPPDATA%\daimon-memory\ on Windows via a shared lib/state-paths.mjs helper added to the byte-parity list (claude-code: prefer %LOCALAPPDATA% on Windows for state files #5, claude-code + codex: share a state-path helper with Windows fallback #8).
• CI now has a windows-latest Git Bash job that runs both client installers end-to-end — it passes, but it can't fully replicate your real setup (Docker Desktop server, your Hermes config).
• hermes: use Python for config.yaml edit to survive Windows line endings #9 I couldn't reproduce against main — left a question on that issue.
• The README now has an explicit Platform support section: Windows is supported via Docker Desktop (WSL2) + Git Bash, exactly the path you proved out.

Could I ask you to retest from current main when you get a chance? Full disclosure: I develop on macOS and don't have a Windows box, so your verification is the real test here. If anything still misbehaves, paste the output and I'll turn it around as fast as I can.

The remaining items (#2, #4, #6, #7, #10, #11, #12) are next on my list — #2 + #4 (AVX2 preflight + recall_tier) first, since your debugging story there is exactly the silent failure I want to eliminate. I'll keep this umbrella open until you confirm the compat fixes work on your machine.