支持SSH远程服务器工作区，Agent可在远端服务器环境执行开发任务（Full SSH Remote Workspace with Persistent Remote Agent Runtime）

[Sakjijdidji55]

Feature Request: Full SSH Remote Workspace with Persistent Remote Agent Runtime

Related to #7369 — this post focuses on user-facing product experience and complete workspace management capabilities, complementing the lower-level runtime persistence design discussion in that thread.

Overview

This feature request aims to enable a complete remote development workflow: the entire DeepSeek Harness runtime, agent loop, session state, and workspace all run natively on a remote Linux server, accessed via SSH from a local client. The local client acts only as a thin UI layer for interaction, while all code, dependencies, command execution, and agent operations stay on the remote server.

Core User-Facing Capabilities

1. Managed SSH Connection Profiles

   • Save and manage multiple remote server configurations (host, port, username, SSH key / password authentication)
   • One-click connect and fast switching between different remote servers and workspaces
   • Built-in connection status indicator and auto-retry for temporary network drops

2. Native Remote File Workspace

   • Full file tree browser: browse, read, edit, create, rename and delete files/directories on the remote server directly from the local UI
   • Built-in diff preview for file changes made by the agent
   • Workspace scoping: mount a specific remote directory as the active working directory

3. Remote Command & Terminal Execution

   • The agent executes all shell commands, build scripts, and tool invocations directly inside the remote server's native environment
   • Interactive terminal access to the remote workspace
   • Configurable approval prompts for high-risk operations (file writes, privileged command execution)

4. Persistent Agent Sessions Across Disconnects

   • The agent loop, multi-step tasks, background jobs, skills, and plugins continue running on the remote server when the local client is closed, asleep, or disconnected
   • Reconnecting resumes the exact same session and event stream, without replaying or duplicating operations
   • Clear task status visibility (not started / running / succeeded / failed / cancelled) when reconnecting mid-task

5. Zero-Touch Remote Bootstrap

   • Automatically deploy, version-check, and start the Harness remote runtime on the target server on first connect
   • No manual Node.js installation, service setup, or port forwarding required from the user
   • Remote runtime listens only on localhost / Unix socket, exposed exclusively via authenticated SSH forwarding

6. Remote-Side Plugin & Skill Loading

   • Plugins and skills load and execute on the remote server, matching the remote environment
   • No local dependency installation or environment setup required to use a remote workspace

Common Use Cases

• Development on cloud servers or remote workstations, where local hardware lacks required compute power, build tools, or dependencies
• GPU-intensive AI/ML workflows where the agent needs direct access to server-side GPUs and runtime libraries
• Multi-environment development (dev / staging / prod servers) with quick workspace switching
• Long-running agent tasks (large refactors, full test suites, deployments) that should continue running while the local machine is offline or closed

Current State & Gap

The existing POSIX SSH provider only remotes low-level primitives (filesystem, subprocess, terminal) to an SSH host, while the agent loop, session state, and task scheduling all remain on the local client. Closing the local client stops all in-progress agent work.

There is also no built-in connection management, workspace switching, or automatic remote deployment — users must manually set up Node.js, start the dsh service, and configure SSH port forwarding themselves.

Additional Notes

• Given Harness's plugin-based architecture, this could potentially be implemented as an official first-party remote workspace plugin
• Aligns with the persistent runtime design discussed in Persistent SSH-hosted Agent Runtime that survives client disconnects #7369, but adds end-to-end user experience and workspace management requirements
• Happy to help test early versions or provide more use case details

[Myoontyee]

Additional Windows Desktop use case: I repeatedly work with the same remote GPU server and would like to save its connection and project selection once, then reconnect from Settings → Connections instead of entering SSH details in each conversation.

Useful acceptance criteria:

• Import/select an existing OpenSSH Host alias, give it a friendly display name, and save a remote project directory. Resolve the current SSH configuration when connecting so changed ports and jump hosts do not leave a stale copied profile.
• Provide Test connection, Connect/Disconnect, connection status, remote terminal and project selection. The UI should clearly show whether files, commands and the Agent run locally or remotely.
• Keep private keys and passwords out of normal preferences, logs and model input. Preserve host-key verification and distinguish authentication, network and missing-runtime failures.
• Qualify Windows Desktop → Linux server explicitly; a POSIX-only client provider should not be described as Windows support.
• Disconnecting/reconnecting must not silently rerun a command. If persistent remote Agent execution is offered, show its actual lifecycle rather than equating an SSH terminal with a persistent Agent.

I am adding these requirements here instead of duplicating the remote-workspace proposal. Related #7369 covers persistent runtime behavior, #7124 asks about Desktop SSH/WSL, and #8724 demonstrates a community connection manager. This is a feature request; I do not yet have a validated Windows implementation of it. No real server addresses or credentials are needed for this discussion.

[Myoontyee]

Partial implementation with explicit scope — 2026-10-08

Added saved OpenSSH-alias selection, friendly names, working directories, read-only connection probing, interactive SSH terminals and dedicated conversations with a pinned ssh_exec tool. Every model command checks the current saved grant and sandbox permission. Revocation and read-only denial have regression coverage. The alias-discovery code adapts Apache-2.0-licensed Yan-Zero/dsh-remote-ssh with notices; OpenSSH itself resolves the authoritative target.

A read-only probe through the new controller also succeeded against a user-authorized Linux machine; no endpoint or credential is published. This is a local DSH Agent controlling SSH, not a persistent remote Agent/runtime. The local PC and DSH must remain running. Interactive terminal I/O passed the Desktop composition smoke; no remote software installation was performed.

Source: 34e4a0292f. This is a custom Windows Desktop implementation on dsh-v0.2.1-alpha.1, not an official release. Focused regression tests: 8 files, 188 passed and 1 skipped. A real Electron/Loader composition smoke passed against disposable repositories; it mocks the model and SSH peer, not the application controllers. Full build and pre-push typecheck passed. No real GitHub PR merge or automatic review was performed.