Transport-Agnostic Process-Control Protocols
cmdop’s process-control protocols are the rules a client follows to work with a live session, independent of any one wire protocol. They cover three things: an attach/detach surface that binds a client to an existing session without owning the underlying process, a live output stream that every attached client shares, and input that is applied in order and attributed to the client that sent it. The protocol is defined over session identity, so a client can drop and reattach without losing the session.
The attach/detach protocol
Attaching binds a client to an existing, addressable session; detaching releases the client without destroying the session. The shape is modeled on IPython kernel messaging, where a client connects to a kernel’s named channels (shell, IOPub, control) rather than owning the kernel process. A client attaches by resolving the session’s identity and subscribing to its stream; it detaches by closing that subscription. The session is unaffected by how many clients are attached — zero attached clients is a valid, live state, and the session survives a client disconnect rather than dying with the connection.
Live output stream
On attach, a client subscribes to the session’s live output and begins receiving its events. The streaming layer follows ZeroMQ pub/sub semantics: output and results are published once and fanned out to every subscribed client, so every attached client sees the same stream. This is the same broadcast discipline an IPython kernel protocol session uses on its IOPub channel to keep multiple front-ends in view of one kernel. Multiple heterogeneous clients — Desktop, CLI, mobile, SDK — can attach to one session at the same time and each receives that shared output.
Ordered, attributed input
Input from clients is applied to the session in order, and each input is attributed to the client that sent it. A client does not act on the session directly; it sends its input over its channel, and the session applies inputs in the order they arrive. Because input carries the sender’s identity, the session — and the audit log — record who sent what. The behavioral contract a client can rely on is simply this: my input lands in order, and it is attributed to me.
Session continuity
Because the protocol is keyed to session identity rather than to one socket, a client can disconnect and reattach to the same session. The wire surface for this is familiar relay topology — a gRPC bidi-stream, a per-session token issued at attach, fan-out to every subscriber, and a continuity token that lets a client reattach within the grace window without redoing authentication. See Sessions for the grace-period and ring-buffer details, and Interactive Attach for the CLI reattach flow.
Why transport-agnostic?
Because the protocol is defined over session identity and channels rather than over SSH/WebSocket/HTTP sockets, the same attach/detach, streaming, and input rules hold regardless of carrier. The agent dials out to the relay over gRPC — outbound only, no inbound port to forward — and clients attach to the session through the relay, not directly to the host. This is precisely what makes transport-independent sessions possible: the control surface never assumes a particular wire protocol.
TAGS: protocols, attach-detach, streaming, session-continuity DEPENDS_ON: [architecture/multi-actor-runtime, architecture/transport-independent-session]
Cmdop