Cline’s cline/cline repository merged a Hub upgrade change that adds cline hub drain and a deliberately staged handoff. It refuses new mutable work before the service is replaced, rather than treating a running agent Hub like a disposable local process.
An agent that can keep working after the chat closes eventually becomes an awkward thing to update. Stop its Hub at the wrong moment and an operator is not merely refreshing a page: they may be cutting across accepted work, a waiting approval, or a client trying to catch up after a dropped connection.
The merged Hub change drains first, checks whether the Hub is idle, stops it only then, and starts a fresh one. If accepted sessions are still active when the wait ends, the command lifts the drain instead of quietly stranding the service in a state where it refuses new work.
A drain is not a pause button
The first angle was simply “Cline gets an upgrade command.” The public implementation makes a more demanding claim. Its Hub now carries a durable event log and a run queue, so a reconnecting client needs more than a live socket after replacement. The new replay path asks for events after a cursor and buffers live traffic while it catches up.
It then deduplicates by stable eventId rather than only by an event’s later durable sequence. That distinction matters when the same logical approval or run event appears once before the log stamps it and once when replay returns the stamped copy.
The command surface and its focused upgrade tests turn that into a legible service contract: do not admit a fresh mutation while retiring; do not replace a busy Hub; and do not make an aborted retirement permanent. It is the operational sequel to durable agent work. A run that can outlive a tab needs a maintenance path that knows it is still there.
The boundary is real only at the handoff
Cline’s source does not prove that every external tool call has finished safely when the Hub becomes idle, nor that these commands are in a released build. It does show a better question for anyone operating durable agents: when you replace the process, which work is no longer admissible, which work has an acknowledged terminal state, and how does a reconnecting client avoid replaying an action as a second action? The next useful public signal is a release-backed replacement test with a live reconnect and an in-flight durable run—not another promise that restarts are harmless.