What is CMDOP?

CMDOP is the reference implementation of the execution-state continuity layer: the live runtime — process tree, shell, sessions, the work in flight — becomes a first-class, single-homed, ownerless object that humans, AI agents, devices, and services attach to as operators. Sessions survive disconnect; you detach, switch device, and reattach without the execution noticing. AI is one kind of operator, not a controller bolted on top.

Concretely, CMDOP delivers that as a private mesh for your own machines. Every participant — a real cmdop agent on a machine, the desktop app, the CLI, and jarvis (a server-side AI agent) — speaks one protocol over a bidirectional relay stream you own. Per-agent identity, the boundaries between machines, and the relay itself are yours; cloud.cmdop.com is optional and a local relay is self-sufficient.

It is not just an SSH manager, and it is not a cloud hub that runs your code. The category is the operator model over a private contour you control. The systems-level framing lives in the Architecture section.

The one-paragraph mental model

Put a cmdop agent on each machine you own — a laptop, a Mac Studio in the office, a VPS like vps-audi. Each agent generates its own Ed25519 keypair and dials out to a relay (yours or the optional cloud one) over gRPC — outbound only, no inbound ports. The desktop app and CLI connect to the same relay as clients. So does jarvis, the server-side AI agent. Because every one of them speaks the same proto over the same bidi stream, a single chat can read logs on vps-audi, restart a service, fan a question out to every machine at once, and have jarvis act on a trigger — all inside one boundary you defined, called a fleet.

The four ideas that matter

• Operators, not controllers. Humans, agents, devices, and services attach to one live execution and steer it together; sessions survive disconnect and reattach from any device. The runtime is the durable thing — every client is a replaceable attached reference.
• One protocol, many operators. Agent, desktop client, CLI, SDK, and jarvis are all operators on the same bidirectional relay stream. There is no separate “agent API” and “client API” — it is one proto.
• You own the private contour. Each agent holds its own Ed25519 identity; fleets draw the boundary around a set of machines; the relay can be entirely yours. See Identity & the private contour.
• Cloud is optional. A local relay is self-sufficient. Run the whole mesh on your own network — air-gapped if you want. cloud.cmdop.com is a convenience, not a dependency.
• AI is one surface, not a bolt-on. Chat is backed by jarvis plus local-LLM models plus cloud/gateway providers — see AI chat.

What CMDOP is, concretely

• A small Go binary, cmdop, that runs on every machine.
• A long-running daemon (cmdop agent start) that holds the outbound relay connection and keeps the machine online.
• A desktop client that wraps the same Go core in a GUI.
• A CLI with the same core, for shells and scripts.
• A Connect subsystem — fleets, machines, and agent-to-agent calls (ask_machine, ask_machines).
• jarvis, the server-side AI agent that runs triggers and webhooks and joins the same proto as an operator.
• An MCP server so Claude Desktop and Cursor call the same tools.

What CMDOP is not

• Not an SSH replacement in the literal sense. It does not hand you a raw TTY into a box you don’t own. It is an agent mesh that handles remote command execution as one of its tools. (cmdop ssh was renamed to cmdop connect — there is no ssh verb.)
• Not a chatbot bolted onto ssh. The agent loop, tools, audit log, and permission gate are first-class.
• Not a hosted service that runs your code in the cloud. Your code runs on your machines, inside your contour.

Who is this for

• A developer with a laptop and a couple of servers who wants one prompt to reach all of them — privately.
• A small team that wants AI to take real action on a fleet they own, without surrendering the relay or the identity keys to a vendor.
• An IDE-bound developer who wants Claude Desktop or Cursor to actually run things through MCP, not just suggest commands.

A note on terminology

The boundary around a set of machines is now called a fleet (/api/fleets). Older docs and the --workspace CLI flag still say “workspace” — same concept.

Read next

Related

• How it works
• Architecture
• Concepts