The Persistent Session Object
A cmdop session is a persistent, network-addressable object: it lives on the control plane, not on a client socket, so it outlives any single connection. A client can disconnect, crash, or be replaced by a different client type; the session keeps running on its host and stays addressable, and a returning client reattaches to it rather than starting cold. The session is the thing clients converge on — its identity, not the transport, is what gets addressed.
What is the session object?
A cmdop session is a single-homed, addressable object that any authorized operator can attach to:
- A live runtime — the process tree keeps running on its host while clients come and go.
- Recent output — a bounded per-session ring buffer makes the latest output available on reattach.
- Session metadata — the session’s identity, state, and lifecycle, held on the control plane.
These are presented to clients as one addressable thing. You attach to the session; you do not attach to a particular connection that happens to be carrying it. See Sessions for the two session flavours and their lifecycles.
Why is it network-addressable?
Because the session is decoupled from the client, it has a stable identity that any operator can resolve. A returning CLI, GUI, API, or AI-agent client reaches the session by a durable handle rather than by the transport connection that happened to be attached — the relay routes by session ID, not by IP. Addressing the session, not the socket, is what lets heterogeneous clients converge on the same running computation. See transport-independent sessions for the lifecycle implications.
What survives a disconnect
The defining property is that the session is first-class and independent of client presence. When the last client detaches, the session is not torn down:
- The runtime keeps running on its host while clients come and go.
- Session metadata and recent output (a bounded ring buffer) are available on reattach, so a returning client resynchronizes against a live session instead of rebuilding from a cold start.
- Across a daemon restart, session state is persisted and recovered.
cmdop sits at the session-state-persistence end of the spectrum: it keeps the session alive and resumable, and replays recent output from the ring buffer. It does not claim full live-memory checkpoint/restore of arbitrary process memory across host death — there is no CRIU-style migration of a session off a dead host. What is shipped, and what is impressive, is reattach: detach from one device and reattach from another and find the session still there.
Relationship to isolation boundaries
A session lives inside an isolation boundary (a Firecracker microVM or a gVisor-style sandboxed kernel), but it is not the boundary. The microVM provides tenancy and security; the session object provides continuity and addressability. Conflating the two is the most common misclassification — addressed directly in classification boundaries.
Conceptual deep dive: the category behind this object is developed in the blog series — The Missing Layer, and Memory Is Not Execution State.
Background reading: The Session as a Computational Primitive — the category essay behind this object.
TAGS: persistent-session, runtime-primitive, persistence, reattach DEPENDS_ON: [architecture/transport-independent-session]
Cmdop