How to connect Claude Desktop to a running development pipeline

You have Claude Desktop on one screen and a Claude Code agent running in another window. Both are local, both are running right now, and they have no idea the other exists. You ask Claude Desktop to explain a tricky part of the codebase, get a clear diagnosis, then manually copy that context into a separate session to start the implementation task. The conversation layer and the execution layer are on the same machine but share nothing.

This gap matters more as the tooling splits into two distinct roles: a conversational client (Claude Desktop, Cursor chat) that you use to think through problems, and an autonomous execution layer (Claude Code, a structured pipeline) that actually runs the work. When they were the same tool, there was nothing to bridge. Now that they are different tools, the coordination falls on you.

why Claude Desktop can't reach a localhost MCP server directly

MCP (Model Context Protocol) is how Claude Desktop connects to external tools. A config entry in claude_desktop_config.json names a server, and Claude Desktop starts that server or connects to it. Simple for a static service.

A development pipeline complicates this. If the pipeline opens a separate MCP server for each project window, each server runs on a different local port chosen at startup. The port is not static. If you add each project as its own config entry, you need to know the port before opening the project, update the config every time you open a new one, and restart Claude Desktop to reload it. That breaks down immediately with multiple projects.

There is also an authentication problem. A raw localhost MCP server with no credentials is reachable by any local process, not just the client you intend. For a controlled development pipeline, that is not a safe assumption.

what a bridge process does

A bridge is a small process that sits between Claude Desktop and your running project windows. Claude Desktop gets one static config entry that points to the bridge. The bridge handles discovery and routing: it finds which project windows are open, identifies which project each holds, and routes each MCP call to the right one. When you open a new project, the bridge picks it up without any config change. When Claude Desktop or a project window restarts, the bridge reconnects.

From your side, the setup is one command to install the bridge and one config snippet pasted into Claude Desktop. After that, every project window you open is automatically reachable without touching the config again. The bridge translates a single static entry into a dynamic, multi-project connection.

Authentication works through the bridge as well. The config entry carries a credential. The bridge rejects connections that do not present it. The pipeline is controlled, not open to any local process.

what you gain once they are connected

With Claude Desktop connected to your development pipeline, the conversation and execution layers share state. You describe a feature in Claude Desktop, it reads the current task backlog, starts the right task in the pipeline, and hands off. You can approve implementation phases without switching windows. You can ask what the running agent just committed and get the actual diff back, not a guess from memory.

More practically: you stop copying context. The diagnosis conversation and the task that acts on it stay in the same session. If you want to send a note to the running agent mid-stage, you send it from where you are. The separation between "talking about the codebase" and "doing work on the codebase" collapses into one surface.

This matters most when you are running more than one task. With a single agent, switching windows is low overhead. With three Claude Code agents running in parallel, checking status across all of them, approving phases, and routing context between conversations becomes unwieldy fast. A connected control surface is where the difference is most visible.

The same connection that gives you a better human workflow is also what makes a manager agent possible. When a manager agent can read the backlog, inspect running stages, and approve or send back phases, the coordination stops being a manual loop. The bridge is what makes the pipeline addressable from any MCP-capable client, not just the app UI. For how that fits into a broader orchestration pattern, see wiring an AI orchestrator into a structured development pipeline and the control-plane framing that explains why it matters at scale.

defract 1.6.0 ships the bridge binary and a Settings > MCP screen that generates the config snippet for Claude Desktop (and Cowork) with credentials already embedded. You copy the snippet, paste it into Claude Desktop's config file, restart once, and every open defract project window is reachable over MCP. The bridge uses Streamable HTTP transport, survives restarts on both sides, and requires no per-project config changes. The defract MCP page has the full API surface if you want to see what operations are available once the connection is live.