[FEATURE]: SSH-based remote server connections to OpenCode Desktop #4731

Open
opened 2026-02-16 17:45:11 -05:00 by yindo · 1 comment
Owner

Originally created by @dl-alexandre on GitHub (Jan 11, 2026).

Originally assigned to: @adamdotdevin on GitHub.

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.
Originally created by @dl-alexandre on GitHub (Jan 11, 2026). Originally assigned to: @adamdotdevin on GitHub. ### Feature hasn't been suggested before. - [x] 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:<localPort>; 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.
yindo added the discussionweb labels 2026-02-16 17:45:11 -05:00
Author
Owner

@github-actions[bot] commented on GitHub (Jan 11, 2026):

This issue might be a duplicate of existing issues. Please check:

  • #6461: [FEATURE]: Named Remote Connections with Session Origin Tracking - Proposes a comprehensive system for connecting to remote environments (Docker, SSH, K8s) with named connections and automatic daemon lifecycle management
  • #6941: [FEATURE]: WSL support connection and SSH forwarding - Requests SSH forwarding capability for WSL connections through the Desktop app
  • #5608: [FEATURE]: OpenCode-Desktop Remote Workspace - Requests remote development workflow similar to VS Code's remote capabilities

Feel free to ignore if this specific SSH tunnel + bootstrap implementation addresses your needs differently than these proposals.

@github-actions[bot] commented on GitHub (Jan 11, 2026): This issue might be a duplicate of existing issues. Please check: - #6461: [FEATURE]: Named Remote Connections with Session Origin Tracking - Proposes a comprehensive system for connecting to remote environments (Docker, SSH, K8s) with named connections and automatic daemon lifecycle management - #6941: [FEATURE]: WSL support connection and SSH forwarding - Requests SSH forwarding capability for WSL connections through the Desktop app - #5608: [FEATURE]: OpenCode-Desktop Remote Workspace - Requests remote development workflow similar to VS Code's remote capabilities Feel free to ignore if this specific SSH tunnel + bootstrap implementation addresses your needs differently than these proposals.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#4731