Persistent SSH-hosted Agent Runtime that survives client disconnects

[dahaipeng]

Motivation

The current POSIX SSH provider family lets filesystem, subprocess, terminal, and sandbox capabilities run on an SSH host while the Harness, Agent Loop, and Session remain on the client host.

This works well while the client is connected, but it does not cover a common remote-development workflow: start a multi-step agent task on a server, close or suspend the local desktop app, and reconnect later while the task continues on the server.

The SSH architecture note currently states:

Persistent remote reconnection needs a separate operation-identity and recovery design; it cannot reuse live callback handles after disconnect.

It also describes moving the complete Harness to the remote host as a separate deployment model. I would like to understand whether that deployment model, or an equivalent persistent remote-runtime design, is planned.

Desired behavior

After selecting an SSH host and remote project:

1. The complete Agent Runtime and authoritative Session run persistently on the remote host.
2. Closing, sleeping, or temporarily disconnecting the local desktop client does not stop the active turn.
3. The remote agent can continue model calls, file operations, shell commands, background jobs, Skills, MCP servers, and host-side plugins.
4. Actions requiring a new user approval pause safely while no client is connected.
5. Reopening the desktop client reconnects to the same Session and resumes the event stream from a durable cursor.
6. An operation submitted before disconnection is queried by a stable operation ID rather than blindly replayed, so commands and mutations cannot execute twice.
7. The remote runtime listens only on a Unix socket or loopback interface and is reached through authenticated SSH forwarding.
8. The remote runtime can be installed, version-checked, upgraded, and rolled back without exposing a public service.

This is different from keeping one shell process alive in tmux or systemd. The complete multi-step Agent Loop should remain active after the local client disappears.

Recovery semantics

A reconnectable protocol would likely need durable identities such as:

• session ID
• turn ID
• monotonic event sequence or cursor
• operation ID
• persisted pending approval ID

For side-effecting work, clients should be able to distinguish at least:

• not started
• running
• succeeded
• failed
• cancelled
• outcome unknown

An ambiguous operation should not be automatically replayed.

Questions

1. Is a persistent SSH-hosted Harness/Agent Runtime planned?
2. Does the deferred “persistent remote reconnection” work refer only to reconnecting the SSH providers, or also to Agent Loop, Session, approvals, and background jobs?
3. Is there an internal design, tracking item, or approximate roadmap for this work?
4. Is the Desktop Connection/RPC layer expected to support a remote Host directly?
5. Would the project accept a community implementation, and which interfaces should it build on to minimize future migration work?