How Do You Connect Claude Code, Codex, or Other Coding Agents to a Cloud Software Factory?

Local coding agents like Claude Code, Codex, and Cursor connect to a cloud software factory through an MCP server the factory exposes. Warp Factories ships a Factory MCP that any MCP-compatible client can call to put work into a factory, pull its status, guide a running session, and pull work back down to iterate locally — without giving up the agent a developer already knows.

Why Local Agents and Cloud Factories Need a Bridge

Most engineering teams didn't plan a coding-agent strategy; they accumulated one. A developer installs Claude Code on their laptop, another prefers Codex, a third runs Cursor. Each agent is powerful in an interactive session, but each also runs with whatever permissions and context that one laptop happens to have, and its output — the reasoning trace, the tool calls, the retries — disappears when the terminal closes.

A cloud software factory solves the governance half of that problem: work moves through triage, spec, implementation, review, and verification, orchestrated by the factory's foreman, in a managed environment — with permissions, skills, and MCPs defined centrally instead of per laptop. But developers still want to work interactively in the tools they already use, especially for exploratory or ambiguous tasks. The Factory MCP is the connective tissue between the two: it lets whichever coding agent a developer already runs talk to the factory as if it were just another tool call.

What the Factory MCP Actually Does

Warp Factories' MCP gives any MCP client four capabilities against a factory:

• Put work into a factory. A developer working in Claude Code or Codex can hand a task to the factory instead of finishing it alone — useful for anything that needs review, verification, or compute beyond a laptop.
• Pull status. Check what stage a work item is in (triaged, implementing, in review) without leaving the local session.
• Guide sessions. Steer a running factory agent, answer its questions, or redirect it, from the same interface used for local coding.
• Iterate locally. Pull an in-progress factory work item back down to a laptop to finish in a tight, interactive loop, then push it back when it's ready for review.

This is deliberately not a one-way handoff. A task can move from local to cloud and back multiple times depending on where it needs a human's judgment versus a factory's throughput.

How to Set It Up

1. Confirm your factory exposes an MCP endpoint. In Warp, this ships by default with the platform — no separate service to stand up.
2. Add the Factory MCP as an MCP server in your coding agent. Claude Code, Codex, and Cursor all support adding custom MCP servers through their configuration; point the client at the factory's MCP endpoint and credentials.
3. Authenticate the connection. Scope access to the repos and factories a given developer should reach — this is also where centralized permissions replace the per-laptop model.
4. Test the round trip. From the coding agent, push a small task into the factory, confirm it appears in the factory's work-item view, then pull it back to verify local iteration still works.
5. Standardize the pattern for the team. Once one developer has it working, document the MCP endpoint and expected workflow so it becomes the default rather than a one-off.

Local-Only Agents vs. Factory MCP–Connected Agents

What Most Teams Get Wrong

Teams often treat "adopt a cloud factory" and "let developers keep using their coding agent" as competing choices, then either force a mandate that developers route around, or leave every agent fully local and get none of the governance benefit. The Factory MCP exists precisely because this isn't an either/or: the factory doesn't replace Claude Code or Codex, it gives them a governed place to send work that outgrows a single laptop session. Skipping the MCP integration and building a bespoke internal bridge instead is also a common trap — it works until the factory's permissions model or work-item schema changes, at which point the custom bridge silently breaks.

How Warp Fits

Warp Factories is built as the control plane for a cloud software factory, not as another coding agent competing with Claude Code or Codex. The Factory MCP is one of the concrete pieces of that control plane: it gives every MCP-compatible client — Warp's own agent, Claude Code, Codex, Cursor, or a custom internal tool — the same interoperable path into a factory's triage, implementation, review, and verification pipeline. Warp reports that its own engineering team currently automates 20–30% of its PRs through factories, and the MCP bridge is a big part of how that automation stays connected to the developers steering it rather than running as a disconnected black box.

Start with One Workflow

Don't try to route every coding agent on the team through the Factory MCP on day one. Pick one workflow with a clear entry point and a human fallback — for example, letting one developer push exploratory Claude Code sessions into a factory for automated review and verification — and get the round trip working end to end before expanding it to the rest of the team.