Operator: One MCP Endpoint, Every Machine

Two days ago I shipped CodeZ -- a self-hosted control plane for Claude Code. Open source. 17 MCP tools. Six waves of features. Orchestration without violating Anthropic's ToS.

It has one limitation: it runs on one machine.

That's fine when you have one laptop. It's not fine when you have a work PC at the office, a Mac at home, cloud containers for throwaway experiments, and a phone in your pocket that should be able to reach all of them.

The problem

CodeZ gives Claude chat full control over Claude Code sessions on a single machine. But the moment you want to run tests on the work PC while refactoring on the home Mac and aggregate the results in one stream -- you're stuck. Each CodeZ instance is its own island. There's no shared namespace, no unified session index, no way for a single MCP client to see across machines.

You end up doing what I've been doing: mentally tracking which machine has which repo, SSH-ing between boxes, context-switching between browser tabs pointed at different tunnels. The orchestration layer I just built stops at the network boundary of one machine.

Introducing Operator

Operator is a multi-machine connection broker that sits on Cloudflare's edge and federates CodeZ instances behind a single MCP endpoint.

The critical design decision: it's an operator, not a router.

Think telephone switchboard. You call the operator and say "connect me to the work machine." The operator knows who's online, patches you through, and gets out of the way. It doesn't decide who you should talk to. It doesn't reroute your call because it thinks it knows better. It connects, and the intelligence stays with you.

This is deliberate. The intelligence sits in the client. Claude.ai has your full context. It knows the task. It knows you said "run the heavy model training on the beefy box." A "smart" router that tried to place work based on heuristics would just get in the way of the agent that actually understands what you're trying to do.

The protocol is five operations:

list_machines()                        → what's online, what repos, what specs
get_machine(machineId)                 → detailed status, active sessions
create_session(machineId, slug, ...)   → client picks the target
send_prompt(sessionId, ...)            → relayed to the right machine
poll_events(sessionId)                 → streamed back through the operator

Underneath, each CodeZ instance maintains a WebSocket connection to the Operator on Cloudflare's edge. The Operator holds those connections and relays messages without transforming them. Clean passthrough. The same MCP tools you use with CodeZ locally -- create_session, send_prompt, poll_events, get_session -- work through the Operator with a machineId parameter that says where.

What this unlocks

The scenario I keep reaching for: I'm on my phone, talking to Claude chat through the Operator MCP connector. I say "start a session in the api repo on the work machine, fix the flaky test in auth.spec.ts, then run the full suite on the home Mac and tell me if it passes."

Claude creates a session on machine A, sends the fix, polls for completion, creates a session on machine B, runs the test suite, polls for that result, and reports back. Two machines, one conversation, zero SSH.

Or: spin up a cloud container for a throwaway experiment. The Operator sees it come online, adds it to the registry. Claude routes disposable work there. When it's done, the container goes away. The session history stays in the Operator's index.

Multi-machine coordination becomes a natural part of the conversation, not a separate infrastructure problem.

Beyond Claude Code

CodeZ is built for Claude Code. The Operator doesn't have to be.

The Operator's protocol is MCP -- the same open standard that Claude, ChatGPT, Cursor, Windsurf, and every other AI tool is converging on. The broker doesn't care what's running on the other end of the WebSocket. It relays MCP messages. If the machine is running Claude Code sessions through CodeZ, great. If it's running something else that speaks MCP, that works too.

Today, CodeZ is the only agent runtime the Operator will support. But the architecture is protocol-native, not product-native. The connection broker is agent-agnostic by design. As the MCP ecosystem grows, the Operator grows with it -- any AI chat interface orchestrating any agent runtime across any machine.

Not open source

CodeZ is open source and will stay that way. Operator will not be.

CodeZ is a tool you run on your machine for your own sessions. The value is in the software itself -- you self-host it, you own it.

Operator is infrastructure. It runs on Cloudflare's edge, maintains persistent connections, aggregates state across machines, and handles auth for multi-device access. The value isn't in the code -- it's in the managed service that keeps the connections alive and the registry consistent.

The hosted Operator will be available at operator.opzero.sh as part of the OpZ platform. If you're already running CodeZ, connecting to the Operator will be a config change -- point your instance at the endpoint, authenticate via MCPAuthKit, and your machine shows up in the registry.

Timeline

I'm building this now. The architecture is documented in the OpZero GitHub org. CodeZ took two days from first commit to open source release. The Operator is a smaller surface area -- one Cloudflare Worker, one WebSocket broker, one SQLite registry -- but the edge deployment and multi-machine testing add complexity.

Expect a working prototype within the week. If you're running CodeZ and want early access, watch the OpZero org or follow the blog.

---

This post is part of the CodeZ series. Previously: Building CodeZ: A Self-Hosted Control Plane for Claude Code.