[FEATURE]: SSH-based remote server connections to OpenCode Desktop #7790
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Summary
Add first-class SSH connectivity to the OpenCode desktop app so users can connect to a remote opencode server through a secure SSH local port-forward. The desktop app continues to speak HTTP/WebSocket to the server via 127.0.0.1:; SSH is transport only.
Goals
• Establish SSH local port-forwards using the system ssh binary (no embedded SSH libs).
• Discover a running remote OpenCode server via a standardized health endpoint over the forwarded port.
• Optionally bootstrap a server via a single remote command execution (no interactive shell workflow).
• Provide clear connection states, diagnostics, and typed error surfaces.
Non-goals
• Remote filesystem access beyond the OpenCode server API.
• Terminal multiplexing / interactive shell access.
• SSH key generation/management/storage.
• SSH config modification/management.
• Remote extension execution.
• Any custom SSH protocol implementation.
Proposed UX
• “Add Connection” wizard for creating a Connection Profile (host + optional user/port/identity file/proxy jump).
• Connect/Disconnect per profile.
• Connection status indicator (Connecting → Discovering → Bootstrapping → Connected / Failed).
• “Copy Diagnostics” action (redacted logs + effective parameters used).
Requirements (high-level)
SSH Transport
• Use system ssh to establish a local forward bound to 127.0.0.1 (local endpoint only).
• Fail fast if ssh would prompt for a password/passphrase (no password prompts in-app).
• Host key verification must be enabled (StrictHostKeyChecking equivalent). Unknown host keys require manual acceptance via ssh outside the app.
• Clean termination on disconnect (SIGTERM then SIGKILL after timeout).
Discovery
• After tunnel is established, probe a standardized endpoint (e.g., GET /health) through the local forward.
• Require 200 OK and JSON including at least status and version.
• Enforce compatibility (e.g., major version mismatch fails with a Compatibility error).
• Timeouts and retry rules should be defined (initial suggestion: 10s per probe).
Optional Bootstrap
• If discovery fails and bootstrap is enabled, run a single remote command (e.g., opencode server start --port=<p> --json).
• Parse JSON output for port/endpoint data, then retry discovery.
• No user-provided arbitrary command args beyond a port number.
• Timeout bootstrap (initial suggestion: 30s) and surface stderr/stdout in diagnostics (redacted).
Profiles & Integration
• Persist profiles locally (JSON in app data dir).
• Support SSH config options commonly needed: Host, HostName, Port, User, IdentityFile, ProxyJump.
• Respect known_hosts; never modify SSH config or known_hosts.
Error Taxonomy / Diagnostics
• Typed errors: Transport, Discovery, Bootstrap, Compatibility, Configuration.
• Expose actionable messages + include redacted raw ssh stderr/stdout in diagnostics.
Open Questions
• How to choose the remote server port (default vs negotiated if 8080 is in use)?
• Whether to support multiple forwards (if bootstrap returns a different port) vs rebuild tunnel.
• What exact /health JSON contract should be considered stable/minimum?
• Precedence rules: profile values vs ~/.ssh/config Host entries.
Acceptance Criteria (MVP)
• User can connect to a host with an already-running remote OpenCode server using an SSH tunnel created by the desktop app.
• If server not running, user can optionally bootstrap it and then connect.
• Errors are typed and diagnosable without exposing secrets.