Remote workspaces in the Desktop app — and the remote side must keep running on its own

[Zessi-C]

What I want

I use DSH Desktop on my laptop and keep a workstation in my office. I would like to open a workspace that lives on that workstation, from the Desktop app, and have it feel exactly like a local workspace — same UI, same plugins, same settings, no second setup.

The one thing that must not be compromised

The remote side has to be a persistent service. Closing my laptop must not stop the work. When I come back and reconnect, the conversation is still there — and it kept running while I was away.

This is the part I care about most, and it is the part that is missing today.

Qoder is the counter-example

Qoder already ships the interface I want: an SSH workspace, where you pick a registered remote host and commands and file operations run there (Qoder execution environments). As a UX reference it is exactly right.

But that mode is not persistent, and that is precisely what I do not want. In my experience with Qoder's SSH workspace, closing the laptop ends the work: the remote side is tied to the local client, the same way VS Code Remote unloads its remote server and cleans up running processes once the client fails to reconnect (vscode-remote-release#1257).

Qoder's own answer for work that must survive is to move it somewhere else entirely: Cloud Tasks, which run in Qoder-managed VMs and keep going when the local terminal disconnects (Qoder cloud mode); and its remote-control and daemon modes explicitly require the local computer to stay active (Qoder remote control).

So the choices today are: connect to a remote, but the work still depends on my laptop staying awake; or move the work off my own machine into someone else's cloud. I want neither. I want the remote-workspace interface and the work living on my own workstation as a service that keeps running on its own.

Where DSH stands today

• The Desktop app can only work on the machine it runs on.
• I can reach my workstation's dsh web through a browser, and the work does keep running there — but that is the web surface, not the Desktop app, and it is a separate world.
• Local and remote are two separate plugin/config sets: I maintain the same plugins twice.
• There is no way to see the remote work from the Desktop app.

The ask

1. Remote workspace in the Desktop app — pick an SSH host, open a remote directory as a workspace, get the normal Desktop experience on it.
2. Remote-persistent by design — the remote side runs as its own service. Laptop closed, network dropped, app quit: the work continues. Reconnect and the conversation is exactly where it was.
3. One plugin/config set — a single source of truth shared by the local and remote sides, instead of maintaining two.

One observation that may be useful

@deepseek-ai/dsh-ssh is already published — and on the next tag it is the same version as the current Desktop build (0.1.7-rc.2) — described as "Shared OpenSSH connection and versioned POSIX remote helper". Nothing shipped in the Desktop app depends on it or bundles it. If that is the intended substrate for this feature, it looks like the foundation is already there and just needs to be surfaced.

Why I am asking for core support instead of shipping a plugin

I looked into solving this as a plugin, and it does not work cleanly. In DSH, the UI's plugin set and the ownership of sessions and agents come from the Host the window is connected to — and the Desktop window always talks to the local Host. A plugin can add tools and panels, but it cannot make the local Host own a remote session without replacing internal core services, which would be fragile across releases. This feels like it belongs in core.

Evidence for maintainers (code references)

• The Desktop window always loads its own local Host: dsh-desktop-host hardcodes runProfile({ profile: 'desktop', args: ['--no-open', '--port', '19387'] }) and reports that URL to Electron (dsh-desktop-host/lib/index.js:215-240, :337). The Electron main process has a single assignment for the host URL, and no environment variable or setting that points it elsewhere.
• The renderer hardcodes the transport: __DSH_TRANSPORT__ = { ownsHost: true, streamBaseUrl } in the frontend bundle; all HTTP is relative-URL, so only the WebSocket origin can be redirected.
• Client plugin bundles are served by the Host: the index HTML loads each plugin as /plugins/??<pkg>/client.js, so the UI component set is decided by whichever Host the window talks to.
• Services are single-provider: ctx.provide() throws when a name is already registered (cordis/lib/index.js:813), and the agent factory is a single slot (dsh-agent/lib/index.js:429). A plugin cannot register a second sessionPersistence / sessionQuery / agent factory.
• A plugin cannot embed the remote UI either: the Desktop main process enforces webview leases and closes any <webview> not created by the approved Browser machinery. The built-in right-sidebar Browser tab works, but it shows the web surface.

Questions

1. Is remote-workspace support planned? I ask because @deepseek-ai/dsh-ssh is published at the same version as the current Desktop build, but nothing shipped uses it.
2. Which shape would you prefer: a configurable remote Host in the Desktop client, a multi-host client, or SSH as a first-class transport?