cowork-to-code-bridge — reaching stdio MCP servers that only exist on the developer's machine

[abhinaykrupa]

chrome-devtools-mcp works because the MCP server runs next to the browser it's
driving. That local-adjacency is the whole point — and it's exactly what breaks
when the client is somewhere else: an agent in a container or a hosted chat
session can't speak stdio to a process on your laptop. The usual fix is exposing
the server over the network, which is a lot of attack surface for what is
supposed to be a local tool.

cowork-to-code-bridge
takes the other route: no listener, no inbound port, no tunnel. A daemon on
your machine watches a shared directory. A remote agent writes a JSON request
file; the daemon executes locally and writes a result file back. Any shared
folder works — bind mount, Syncthing, Dropbox. The machine never accepts an
inbound connection.

The piece relevant here is mcp_proxy.sh: it relays a single JSON-RPC call to a
local stdio MCP server and returns the response through that same file queue.
So a sandboxed agent can drive a machine-only MCP server — including a
devtools-style one bound to the local browser — without that server ever being
reachable from the network. There's also mcp_audit.sh, which dumps the MCP
servers registered in the local Claude Code so you can diff what the machine has
against what your remote agent can actually reach; the mismatch is usually the
bug.

Guardrails, since this is executing things: the daemon only runs allow-listed
scripts from its scripts directory, tasks are cancellable (SIGTERM to the process
group, then SIGKILL), output is size-capped, and results carry real exit codes.
MIT, Python client, macOS + Linux.

Posting here because this community thinks hard about local-first MCP transports
— genuinely interested in whether the file-queue approach holds up against cases
you've hit, or where you'd expect it to fall over.