[Windows] MCP server config generated as macOS-only /bin/sh and re-clobbered on every server spawn -> spawn /bin/sh ENOENT

[fujunlin-git]

Summary

On Windows, ok registers a macOS/Unix-only MCP server command into both the project .mcp.json and the global ~/.claude.json (Claude Code), and re-writes it on every server spawn (ok init, ok start, and the MCP server's autostart). The generated command is command: "/bin/sh" with a script that only looks for OpenKnowledge.app and Unix npx paths. Windows has no /bin/sh, so the host fails to launch it:

MCP open-knowledge: spawn /bin/sh ENOENT
MCP open-knowledge: Server disconnected.
Could not attach to MCP server open-knowledge

Because the config is regenerated on every server spawn, any manual Windows fix is overwritten the next time ok start runs or the MCP server autostarts — so the error keeps coming back.

Environment

• OS: Windows 11 Pro (10.0.26200)
• Node: v24.11.1
• @inkeep/open-knowledge: 0.19.2 (CLI + server), installed via npm i -g
• Host: Claude Code (MCP client). The same generated config also lands in Cursor / Codex / OpenCode config files.

Steps to reproduce

1. On Windows, npm i -g @inkeep/open-knowledge
2. In a project dir: ok init
3. Observe the generated .mcp.json (and the mcpServers.open-knowledge entry written into ~/.claude.json):

{
  "mcpServers": {
    "open-knowledge": {
      "command": "/bin/sh",
      "args": ["-l", "-c",
        "# ok-mcp-v1\nUSER_BUNDLE=\"$HOME/Applications/OpenKnowledge.app/Contents/Resources/cli/bin/ok.sh\"\n… BUNDLE=\"/Applications/OpenKnowledge.app/…\" … command -v npx … for d in \"$HOME/.nvm/…\" /opt/homebrew/bin /usr/local/bin …; do … done\necho \"OpenKnowledge: install OK Desktop or Node.js 24+, then restart your editor\" >&2\nexit 127"
      ]
    }
  }
}

4. The MCP client (Claude Code) tries to spawn /bin/sh → spawn /bin/sh ENOENT, server never attaches.
5. Hand-fix the config to a Windows command (below) → it works. Then run ok start (or let the MCP server autostart a project server) → the file is rewritten back to the /bin/sh form and the error returns.

Expected

• On Windows, generate a launchable command (no /bin/sh dependency).
• Do not silently overwrite a user-customized MCP config on every server spawn; or provide a flag/env to opt out of MCP-config registration.

Actual

• Only a macOS bundle path + a Unix npx fallback are emitted; there is no Windows branch, so the command is unlaunchable on Windows.
• The config is (re)written on ok init, ok start, and MCP autostart, clobbering manual fixes.

Working workaround (Windows)

Replacing the entry with an explicit Windows command makes the MCP server attach and complete the initialize handshake (serverInfo: open-knowledge v0.19.2):

{
  "mcpServers": {
    "open-knowledge": {
      "command": "cmd",
      "args": ["/c", "C:\\Users\\<me>\\AppData\\Roaming\\npm\\ok.cmd",
               "--cwd", "<project-dir>", "mcp", "--no-bundle-proxy"],
      "env": { "HOST": "127.0.0.1" }
    }
  }
}

But this is overwritten on the next server spawn (see above).

Suggested fixes

1. Windows-aware config generation. Emit a Windows-launchable command instead of /bin/sh — e.g. cmd /c ok.cmd … mcp (or a node <cli> mcp invocation, or platform-branch the generated command).
2. Don't clobber user edits. If the open-knowledge MCP entry already exists and differs, leave it (or merge non-destructively), and/or add an env/flag like OK_SKIP_MCP_REGISTER=1 to skip registration on ok start / autostart.

Related Windows findings (same setup; may be separate issues)

• MCP-autostarted server binds IPv6 ::1 only. The MCP client's edit / exec calls connect to 127.0.0.1 and fail with Server unreachable: fetch failed / "actively refused". Confirmed via Get-NetTCPConnection: the autostarted server listens on ::1:<port> only, while the ok ui process dual-stacks. Workaround: start with --host 127.0.0.1 or env HOST=127.0.0.1.
• Auto-sync (autoSync.enabled in .ok/local/config.yml) is only read at server startup. Toggling "Git auto-sync" ON in the editor UI writes enabled: true, but a server that was already running keeps syncEnabled:false (log: [sync] trigger(sync) ignored — state=disabled); it only takes effect after a server restart. Consider hot-reloading the sync setting, or documenting that a restart is required.

---

Filed with help from Claude Code. Happy to provide more logs or test a fix on Windows.

[nick-inkeep]

Thanks @fujunlin-git , we'll investigate.

[mike-inkeep]

@fujunlin-git thank you for the report. The MCP config and the IP address binding issue should both be fixed for Windows in the next release. The autoSync issue will be addressed in a separate PR

[fujunlin-git]

Upgraded to 0.26.0-beta.5 on Windows 11 (Node 24) and verified two of the three fixes end-to-end:

• ✅ windows-mcp-config-chain — ok init now generates a Windows-native launcher (powershell -NoProfile -NonInteractive -Command with a # ok-mcp-win-v1 script that resolves ok.cmd / npx.cmd), in both the project .mcp.json and ~/.claude.json. No more /bin/sh, and re-running ok start now rewrites the correct Windows config instead of clobbering it back to the macOS form.
• ✅ windows-ipv4-loopback-bind — ok start (no --host) now binds 127.0.0.1 directly (confirmed via Get-NetTCPConnection), so the MCP client no longer hits Server unreachable: fetch failed connecting to the loopback.

Haven't yet verified autosync-toggle-hot-apply and fix-non-ascii-filename-sync from a fresh MCP-client session (need an editor restart to pick up the new server) — will follow up. Thanks for the fast turnaround!

[fujunlin-git]

Restarted the editor (fresh MCP client on 0.26.0-beta.5) and verified the rest:

• ✅ autosync-toggle-hot-apply — auto-sync is now active on the running server (previously logged state=disabled). An MCP edit auto-committed and pushed to the remote with no manual git; local and remote match. (A couple of transient [sync-error] DNS resolution failed blips self-recovered.)
• MCP edit now works with zero workarounds — no --host, no hand-edited config, no fetch failed.

So all three reported issues are resolved on 0.26.0-beta.5. 🎉

One separate, still-present Windows quirk (likely unrelated to the sync fix): exec's raw cat/ls stdout returns cat: <file>: No such file or directory for both ASCII and non-ASCII paths, while the enriched metadata (frontmatter / backlinks / previewUrl) resolves correctly — so edit / search work but exec cat can't return file bodies on Windows. Happy to file this separately if useful.

[miles-kt-inkeep]

Hey @fujunlin-git , we will look into the separate issue thanks for the report!

[mike-inkeep]

@fujunlin-git I've merged a fix for that here: 478904d