## What changed - `codex-stdio-to-uds` now tolerates `NotConnected` when `shutdown(Write)` happens after the peer has already closed. - The socket test was rewritten to send stdin from a fixture file and to read an exact request payload length instead of waiting on EOF timing. ## Why this fixes the flake - This one exposed a real cross-platform runtime edge case: on macOS, the peer can close first after a successful exchange, and `shutdown(Write)` can report `NotConnected` even though the interaction already succeeded. - Treating that specific ordering as a harmless shutdown condition removes the production-level false failure. - The old test compounded the problem by depending on EOF timing, which varies by platform and scheduler. Exact-length IO makes the test deterministic and focused on the actual data exchange. ## Scope - Production logic change with matching test rewrite. |
||
|---|---|---|
| .. | ||
| src | ||
| tests | ||
| BUILD.bazel | ||
| Cargo.toml | ||
| README.md | ||
codex-stdio-to-uds
Traditionally, there are two transport mechanisms for an MCP server: stdio and HTTP.
This crate helps enable a third, which is UNIX domain socket, because it has the advantages that:
- The UDS can be attached to long-running process, like an HTTP server.
- The UDS can leverage UNIX file permissions to restrict access.
To that end, this crate provides an adapter between a UDS and stdio. The idea is that someone could start an MCP server that communicates over /tmp/mcp.sock. Then the user could specify this on the fly like so:
codex --config mcp_servers.example={command="codex-stdio-to-uds",args=["/tmp/mcp.sock"]}
Unfortunately, the Rust standard library does not provide support for UNIX domain sockets on Windows today even though support was added in October 2018 in Windows 10:
https://github.com/rust-lang/rust/issues/56533
As a workaround, this crate leverages https://crates.io/crates/uds_windows as a dependency on Windows.