feat(serve): supported remote folders — connect clients to a remote daemon and manage its workspaces/sessions #11475

What would you like to be added?

A supported remote-development workflow for qwen serve: the interactive client runs locally, while the daemon, workspace, and agent execution remain on a remote host. Build on the existing remote Web Shell and multi-workspace/session APIs rather than introducing a separate remote execution stack.

The three user-facing goals are:

1. Connect to a remote daemon. Give first-party clients (Web Shell, desktop shell, SDKs) a documented connection/authentication contract, with a clear target host, connection status, and reconnect behavior. The desktop needs an explicit external-daemon attachment mode; Web Shell already supports same-origin remote access.
2. Manage the remote daemon's workspaces. Select remote directories, register/remove eligible workspace runtimes, and inspect trust/runtime status. Reuse the existing typed-path and directory-suggestion UI; a native picker on the daemon host cannot be required for headless servers.
3. Manage remote sessions. Discover sessions across the daemon's workspaces, attach/reconnect, and expose distinct actions for stopping a turn, releasing a live session, archiving history, and deleting history.

Why is this needed?

Code often lives on a remote development server while the interactive client runs on a laptop. The remaining work is a coherent client-to-remote-daemon workflow, especially desktop attachment and explicit ownership/recovery semantics—not making remote browser access possible for the first time.

Current baseline and corrections

Static source review against main at 6d68ea9236e1fcf7b427b8428b694f8089b38aef (2026-09-09); this is not an end-to-end verification or a claim about every published release.

• Remote Web Shell already has a documented path. feat(serve): one-command remote start with a generated token, same-origin shell access, and a pairing QR #11172 merged same-origin remote startup improvements, including generated bearer tokens. The current serve guide documents remote access, origins, and TLS. Its “Deployment surface — local-only” sentence belongs to the historical v0.16-alpha known limits section. The cross-origin ?daemon= restriction does not prohibit same-origin access to a remote daemon.
• Workspace registration UI already exists. AddWorkspaceDialog wiring supports typed paths and suggestions. A single-workspace daemon also exposes its primary path through workspaceCwd; an omitted optional workspaces[] does not make that workspace undiscoverable.
• Cross-workspace session discovery already has a client-side implementation. The sidebar queries secondary workspace catalogs. Absence of a daemon-wide list endpoint does not imply absence of discovery. New aggregate endpoints should require a demonstrated pagination, sorting, or request-scaling need, not be prerequisites for this issue.
• Desktop attachment is a lifecycle change, not just a URL allowlist change. The desktop runtime owns a bundled child process and stops it on shutdown. Its loopback listening-line validation should remain distinct from connecting to an independently managed daemon.

Additional context

Proposed initial scope

Start with one explicitly configured, already-running remote daemon: authenticated HTTPS, or a documented SSH tunnel to its loopback endpoint. Manual connection details are sufficient initially. Decide separately whether the client should bootstrap/manage the remote daemon over SSH; that introduces installation, versioning, and process-ownership responsibilities.

Keep automatic discovery, cloud relays, daemon-to-daemon federation, cross-host session migration, and multi-user hosting out of the first milestone. This is client-to-one-daemon access, not cross-host coordination. Mounting a remote directory into a locally running daemon remains out of scope; #10962's client-filesystem bridge is a different direction.

Architecture requirements to settle

1. Execution and identity ownership. Normal workspace file operations, shell/Git commands, environment, and daemon-side tools/MCP run on the selected daemon host. Any client-local bridge must be explicit. Qualify client-side session/workspace identity, cached state, and credentials by connection so switching hosts cannot mix them. A tunnel endpoint named localhost must not imply that the workspace or native picker is on the client machine.
2. Lifecycle ownership. Closing a tab, disconnecting, or quitting an attached desktop client must not stop an externally managed daemon or implicitly cancel its work. Define stop-turn, detach/release, archive, and delete separately. Removing a workspace registration must not delete its source directory; existing primary/startup removal restrictions still apply.
3. Reconnect and recovery. Reuse existing SSE cursor/epoch and snapshot mechanisms. Specify recovery when replay is unavailable, how pending approvals become visible again, and how a lost submission response is reconciled without blindly submitting the prompt twice. Distinguish transport reconnection from daemon restart: recovering persisted history does not promise continuation of an interrupted tool/process.
4. Security and compatibility. Document TLS/SSH setup, origin/Host checks, credential storage and token renewal/replacement, plus incompatible client/daemon behavior. Do not weaken local-child validation or browser origin checks globally. A daemon operator token is not a per-workspace ACL, and workspace trust is not tenant isolation. Authentication or target-workspace failures must not fall back to a local or primary runtime.

Acceptance criteria

• From a separate client machine, connect to the remote host using the documented secure path; show the target host and connection state.
• On a headless daemon, discover the primary workspace, register an additional directory using typed paths/suggestions, and inspect trust/runtime status without a server-side GUI.
• Discover and attach to sessions in both workspaces using existing APIs where sufficient. File edits and shell/Git commands affect only the selected remote workspace.
• Disconnect during a turn, reconnect, and recover current state without duplicate prompt execution. Pending approval requests remain recoverable; disconnecting does not count as approval.
• Quit the attached client without killing the externally managed daemon. Reopen and reconnect. Test daemon restart separately and document what is and is not recoverable.
• Invalid/replaced credentials, an unavailable host, an incompatible daemon, or an unavailable workspace produce explicit errors, without silently changing the execution target. If SSH forwarding is supported, verify it against the existing Host/origin checks.
• Unregistering an eligible workspace leaves its source files intact; destructive session-history actions are distinct from disconnecting or stopping a turn.

Related: #3803 (daemon proposal), #6378 (multi-workspace RFC), #11172 (remote startup), #10962 (client-filesystem bridge), #4514 (broader daemon roadmap; federation is separate from this request).