MCP bridge: Windows support stubbed — needs named-pipe or TCP-loopback transport

[benhoverter]

Summary

The openfang-mcp-bridge crate and the daemon-side bridge_ipc module are structurally unix-only: their IPC contract is a unix domain socket on a filesystem path. On Windows, all UnixStream/UnixListener-touching code is currently #[cfg(unix)]-gated so the workspace compiles cleanly, but the bridge is functionally absent: the daemon boots, but any MCP-routed tool invocation has no transport.

Net effect for Windows users: daemon runs; MCP tools do not.

Current state (post-fix)

• crates/openfang-mcp-bridge/src/main.rs — entire body gated #[cfg(unix)]. Non-unix fn main() prints an unsupported-platform message and exits with code 1.
• crates/openfang-api/src/lib.rs — pub mod bridge_ipc is #[cfg(unix)].
• crates/openfang-api/src/server.rs — BridgeIpcServer::start() is #[cfg(unix)]; the non-unix shim logs an info line and returns, leaving the daemon's existing "no bridge socket" fallthrough to handle downstream callers.
• Tests: gated #[cfg(all(test, unix))]. No coverage runs on Windows for these crates.

CI: Windows Check + Test now green; Linux/macOS unchanged.

Why this is a stub, not a fix

Unix domain sockets don't exist on Windows. The current code:

use tokio::net::{UnixStream, UnixListener};

…has no Windows analog at the tokio::net level. Two real options:

Option 1 — Named pipes (Windows-native)

Use tokio::net::windows::named_pipe::{NamedPipeServer, NamedPipeClient}. This is the closest semantic match to unix domain sockets:

• Filesystem-namespace-like addressing (\\.\pipe\openfang-bridge)
• Per-pipe ACLs (security model parallel to unix socket file perms)
• Stream semantics; existing length-prefixed framing codec works unchanged

Requires abstracting the transport behind a trait (e.g. BridgeTransport: AsyncRead + AsyncWrite + Unpin + Send) with two backends:

• unix::UdsTransport wrapping UnixStream
• windows::PipeTransport wrapping NamedPipeClient/NamedPipeServer

Connection establishment differs slightly (named pipes use ClientOptions::open with retry rather than connect), so the connect path needs platform branches. Server-side: NamedPipeServer requires re-creating the server instance after each accept, vs. UnixListener::accept reusing the listener — known named-pipe quirk worth modeling explicitly.

Option 2 — TCP loopback (127.0.0.1:<ephemeral>)

Single-backend: TcpListener::bind("127.0.0.1:0"), write the bound port to a known file (~/.openfang/run/bridge.port or registry equivalent), bridge clients read it.

Pros: one code path, no cfg branches; works on every platform tokio supports.

Cons: weaker auth posture (any local process can connect() to the loopback port — unix sockets get filesystem-perm-based isolation, named pipes get ACLs, loopback gets neither without app-layer auth); port-coordination protocol (write port to file, handle stale files, race conditions on concurrent daemons); a token-handshake on connect would mitigate the auth gap but adds protocol surface.

Recommendation

We'd lean Option 1 (named pipes), because auth-model parity with unix sockets keeps the trust story consistent across platforms, and abstracting transport behind a trait is the right shape regardless — it also leaves the door open to remote-bridge transports later (Option 3 territory: TCP+TLS for cross-host bridging) without further refactor. Happy to defer to maintainers' call if there's context we're missing.

Acceptance criteria

• Bridge transport abstracted behind a BridgeTransport trait (or equivalent).
• Windows backend uses tokio::net::windows::named_pipe (or alternative chosen by maintainers).
• Unix backend behavior unchanged.
• openfang-mcp-bridge Windows build is functional, not stubbed; #[cfg(unix)] gates added in the prior fix are removed.
• Test coverage runs on Windows for the bridge crate (smoke test: spawn daemon, spawn bridge client, exchange a frame).
• Daemon's non-unix BridgeIpcServer::start shim removed.
• CI: Windows Check + Test green with bridge tests enabled.

Out of scope

• Cross-host / remote bridge transport (separate concern; would be Option 3).
• MCP server/client semantics changes — this issue is purely about transport.

Context

The current #[cfg(unix)] gates were introduced in PRs #1182 and #1183 to unblock Windows CI. Those PRs' primary scope was capability enforcement and file policy, not platform support; the gates are intentionally a stub. This issue tracks turning the stub into actual Windows support.

[jaberjaber23]

Triage confirms the diagnosis. Searched the tree: openfang-mcp-bridge isn't present as a separate crate on main yet, but the #[cfg(unix)] gates on BridgeIpcServer in crates/openfang-api/src/server.rs (lines 927, 948, 982) and the corresponding gates in routes.rs:8622 match what you described. So the design discussion for the standalone crate lands here.

Recommendation: Option 1 (named pipes), with the trait abstraction even if we shipped Option 2 first.

Reasoning:

• Auth-model parity matters more than people think. The MCP bridge is the path through which arbitrary tool calls hit the daemon. A loopback TCP port with no app-layer handshake means any unprivileged process on the box (browser extensions, crash reporters, half the SaaS clipboard tools) can connect() and start invoking tools. Named-pipe ACLs via tokio::net::windows::named_pipe::ServerOptions::new().pipe_security(..) give us the Windows analog of 0600 on a socket file. UDS already gates by filesystem perms; we want the Windows side to gate equivalently, not weaker.
• Token handshake on loopback is technically sufficient (HMAC over a ~/.openfang/run/bridge.token shared secret, constant-time compare via subtle — same pattern as FIX 7 for OFP wire). But that's additional protocol surface on every connect, on every platform, that exists only because we cheaped out on transport. Better to put the trust at the transport layer where it belongs.
• The trait abstraction (BridgeTransport: AsyncRead + AsyncWrite + Unpin + Send) is the load-bearing piece. Once it exists, swapping/adding backends is mechanical and we can ship Option 3 (TCP+TLS, cross-host) later as a third impl without touching call sites.

Concrete shape:

// crates/openfang-mcp-bridge/src/transport/mod.rs
#[async_trait]
pub trait BridgeListener: Send + Sync {
    type Conn: AsyncRead + AsyncWrite + Unpin + Send + 'static;
    async fn accept(&mut self) -> std::io::Result<Self::Conn>;
}

• unix::UdsListener wraps tokio::net::UnixListener (unchanged behavior).
• windows::PipeListener wraps tokio::net::windows::named_pipe::NamedPipeServer with the re-create-after-accept dance: each accept() call awaits server.connect(), returns the connected handle, then immediately creates a fresh NamedPipeServer for the next accept. That quirk is well-documented in the tokio docs and worth a comment in the impl so future readers don't think it's a bug.
• Address: \.\pipe\openfang-bridge (or \.\pipe\openfang-bridge-{user_sid} if we want multi-user-per-host isolation without ACL parsing).
• Client side uses ClientOptions::new().open(path) with a small retry loop on ERROR_PIPE_BUSY — also a known quirk.

Framing: the existing length-prefixed codec works unchanged. Both transports are byte streams.

Tests: #[cfg(windows)] smoke test analogous to the existing unix smoke test: spawn a PipeListener, connect a NamedPipeClient, round-trip a frame. CI matrix gets a Windows job for this crate.

Blocker: the named-pipe re-arm-after-accept dance interacts badly with naive accept() loops written for UnixListener semantics. We can't just while let Ok(conn) = listener.accept().await and hand the conn off — we have to construct the next NamedPipeServer instance before yielding the current one, or there's a race window where a connecting client gets ERROR_FILE_NOT_FOUND. The BridgeListener trait has to express "accept also implicitly re-arms" in its contract, or the Windows impl has to maintain a one-step-ahead pending: NamedPipeServer field internally. Latter is cleaner. That's the actual design call to make before any code lands.

References: tokio named-pipe docs at https://docs.rs/tokio/latest/tokio/net/windows/named_pipe/index.html, and the Windows IPC security model writeup at https://learn.microsoft.com/en-us/windows/win32/ipc/named-pipe-security-and-access-rights for the ACL surface.