What is CMDOP?

cmdop is a platform for machine-to-machine command execution: connect machines over an outbound-only relay and run commands node-to-node, including agent-to-agent, without opening inbound ports. Each machine dials out to its relay, so it stays reachable from behind NAT or a firewall with no port forwarding and no VPN.

What you work in is a machine workspace: a conversation attached to a real joined computer, with an optional project folder and an execution engine. It is built for work that continues — not for a one-off administration panel, and not for a marketplace with chat bolted on.

The everyday loop is simple: choose a machine, start or resume a conversation, choose a Project Root when repository context matters, select CMDOP, Claude Code, or Codex, and review the result. Come back later and pick up where you were.

The idea underneath

CMDOP is an execution-state continuity layer: the thing that keeps live work on a machine coherent while the people and programs attached to it come and go.

Three properties follow, and they are what actually distinguish the product:

• Execution state is single-homed. One machine owns the state for its work, so there is exactly one place the truth lives. Operators are spread across browsers, terminals, and clients; the state is not.
• A session survives disconnect, and you observe it directly. Close the laptop and the work continues. Come back and you reattach to live state — you are not watching a reconstruction assembled from a log.
• AI is an operator, not a controller. The model attaches to the same session you do and works alongside you inside the same boundary, instead of taking the wheel while you watch.

The blog series treats this in depth.

What runs where

• The cmdop binary runs on the machine that has the files, tools, and execution authority. It dials outward to its relay; nothing dials in.
• Its embedded relay serves the web console and connects the machine to the rest of its fleet.
• The browser is a client. It renders the model and requests explicit actions — it never becomes the authority for project paths, session identity, or machine permissions.
• CMDOP’s built-in engine uses the CMDOP Router; Claude Code and Codex use their locally installed CLIs and existing sign-in.

CMDOP also exposes operational and interoperability surfaces — relay management, Skills, external MCP tools, and fleet MCP. They support the workspace; they are not the primary work loop.

What it is not

• Not a hosted computer that executes your project in the cloud. The work runs on your machine.
• Not SSH with a chat window. A session belongs to the machine, so it outlives the connection you reached it on.
• Not an MCP server or Skill marketplace first. Those are distinct surfaces with their own lifecycles.

Common questions

What is Cmdop in one sentence?

Cmdop is machine-to-machine command execution over an outbound-only relay: a joined machine dials out, stays reachable without an inbound port, and exposes a durable machine workspace where humans and AI can operate the same live session.

Does Cmdop require SSH or port forwarding?

No. SSH can still be useful for direct shell work, but Cmdop’s normal path does not require an SSH daemon, port forwarding, or a VPN. The machine agent dials out to its relay, so nothing has to dial in.

Where does the work actually run?

The work runs on the joined machine that owns the files, tools, and session. The browser, terminal, SDK, and MCP clients are operators attached to that machine’s live session; they are not separate places where execution state is copied.

Read next