How CMDOP works

CMDOP runs commands on a machine without that machine accepting any inbound connection. The agent installed on it makes an outbound connection to its relay and keeps it open; nothing dials in. That is why a joined machine works from behind NAT or a firewall with no port forwarding and no VPN, and why “online” means “its connection is live” rather than “a port is open”.

On top of that reach, CMDOP keeps the normal path focused on one outcome: work with a selected machine through a durable conversation.

The work loop

1. Choose a machine. A joined machine supplies the files, tools, and execution authority for the work.
2. Start or resume a conversation. A conversation is a durable work thread, not a browser tab or a transient prompt.
3. Choose a Project Root when needed. Project scope keeps repository work attached to the selected machine and folder.
4. Choose an execution engine. Use CMDOP, Claude Code, or Codex according to the work. An engine remains associated with the conversation it began.
5. Review and continue. Results, files, and conversation history remain available when you return.

The web console is the primary client for this loop, and the terminal chat is a full second door into the same conversation. Files and Project Context help you inspect the same machine and project; they do not silently run work or change the conversation’s scope.

Why leaving and returning works

The conversation you see is the visible part of a live session that lives on the machine — not in your browser tab.

• The session survives your disconnect. Work in flight keeps running when you close the client.
• Reattaching shows live state, not a replay reconstructed from a log of what happened while you were away.
• The state is single-homed. One machine owns the execution state for its work, so two clients cannot drift into two versions of it.
• Sessions are ownerless. You, another client, and the AI can all be attached at once; nobody holds an occupancy that locks the others out. What each may do is decided separately, by permissions.

Context binds when a session begins

A conversation keeps the engine it started with, and a change that would alter execution semantics — a different project, for instance — starts a new conversation rather than silently changing the ground under an existing transcript. Past work keeps the meaning it had when it was done.

Engines and models are different choices

CMDOP, Claude Code, and Codex are execution engines. A model choice affects how an already-selected engine reasons; it does not change the selected machine or project. CMDOP does not manage credentials for a locally installed external CLI.

Supporting surfaces

The local relay and CLI make the workspace available and help operate the machine. Skills, external MCP tools, and fleet MCP each solve different interoperability problems. Use them deliberately after the base machine and conversation workflow is working.

For a product-level component map, see System overview.

Common questions

Do I need to open a port to run commands on a remote machine?

No. The Cmdop agent on the target machine makes an outbound connection to its relay and keeps it open, so nothing dials in. The machine works from behind NAT or a firewall with no port forwarding and no VPN. For a server workflow, see Run an AI agent on a server without SSH.

Does Cmdop work on a machine behind NAT or CGNAT?

Yes. Because the agent dials out rather than listening, a machine with no public IP and no forwarded port is still reachable. It needs outbound HTTPS and nothing else. See Reach a machine behind NAT for the walkthrough.

Do I need a VPN to use Cmdop?

No. Cmdop does not route arbitrary network traffic and does not need a VPN to reach a machine. If you need service-to-service connectivity by IP, that is a VPN or mesh network’s job, and the two can be used together — see Where Cmdop fits.

What happens to my work if I close the browser or lose the network?

The session lives on the machine, not in your client, so work in flight keeps running. When you return you reattach to live state rather than a replay reconstructed from a log.

Can one AI agent operate another machine?

Yes. A local assistant can use Cmdop’s fleet MCP tools to list joined machines, ask a target machine’s own agent to do work, or run a bounded command there. The target is still a joined machine with its own online state and access boundary; the assistant is not given a raw network path or a copy of that machine’s local shell.