feature: connect to remote servers

[nickjvandyke]

Did you check the docs?

• I am using the latest plugin version
• I read the plugin docs
• I read the opencode docs

Is your feature request related to a problem? Please describe.

Most of us run opencode (which dual-launches the server and TUI) locally, for which the plugin works great. However its remote-server uses are growing and opencode.nvim can't connect to those because we hard-code localhost.

Describe the solution you'd like

Expose server.host configuration (maybe server.hostname to match opencode's CLI flags?). Default to localhost. Use it in Server:curl.

The user has likely configured the remote server with basic auth, so we should support that too via server.username and server.password.

Questions:

• Do we need to expose server.protocol too? Is it reliable to use http for localhost, and https otherwise? Can we self-reference in the defaults like that? Or has to be inline, and not configurable? What about edge case locals like 127.0.0.1 and 0.0.0.0, or Docker internal URLs that are "remote" but SSL-less?
• Can we always default the username and password to the env vars (which may or may not be set)? Will a server with no auth set care if the request still includes it?
  • Edit: Yup! Works fine.
• Because we leverage TUI commands, I believe we still need an attached TUI ultimately? If so, perhaps we change the server command to opencode attach when we detect a remote host? Maybe we pass an args list to server.start for the user to concat to their opencode cmd, conditionally including attach and/or --port <opts.server.port>. Lower maintenance and more straightforward than the previous opts.server.cmd.

Describe alternatives you've considered

No alternatives afaik. opencode attach <remote server> locally doesn't work because we must make requests to the server, not the attached TUI.

We could expose server.url instead of the separate host and port (and protocol?) fields. It's nicer for remote config - just copy/paste the entire URL. But it adds noise (and breaks backwards-compat) for the most common localhost case, has worse intellisense, and requires internal parsing. With just host and port, remote configuration is NBD. If we need protocol, it gets a bit annoying. But still the lesser evil.

Note that whatever URL configuration we choose above, we'll also use in an eventual configurable server discovery process.

Additional context

Related:

• feature: interact with opencode server without TUI #190
• feat(server): support remote server connection and authentication #159
• feature: support arbitrary server discovery #197

[tianqiii]

A useful feature! Currently I use a ssh port forwarding wrapper to launch opencode goes like:

sshoc() {
  local port=11435
  local remote="$1"
  [ -z "$remote" ] && { echo "usage: sshoc <user@remote-host>"; return 1; }
  # reuse if tunnel exists
  if pgrep -af "ssh.*-R ${port}:127.0.0.1:${port}.*${remote}" >/dev/null 2>&1; then
    echo "[sshoc] tunnel exists"
  else
    if ! ssh -fN \
      -o ExitOnForwardFailure=yes \
      -o ServerAliveInterval=30 \
      -o ServerAliveCountMax=3 \
      -R "${port}:127.0.0.1:${port}" \
      "$remote"; then
      echo "[sshoc] failed to create tunnel"
      return 1
    fi
    echo "[sshoc] tunnel up: ${remote} localhost:${port} -> local 127.0.0.1:${port}"
  fi
  # attach if there is a local opencode server instance, otherwise launch a new one
  if command -v lsof >/dev/null 2>&1 && lsof -iTCP:"$port" -sTCP:LISTEN -t >/dev/null 2>&1; then
    echo "[sshoc] detected opencode listening on ${port}, attach it."
    opencode attach "localhost:${port}"
  else
    echo "[sshoc] start opencode on port: ${port}"
    opencode --port "$port"
  fi
}

Companion setup:

• On the remote server, set server = { port = 11435 } in lua/plugins/opencode.lua
• Mount the remote repository locally with sshfs to provide context for the local OpenCode instance

[dngray]

I would love to see this, the goal I actually had was to run opencode in a completely seperated opencode podman container which is confined by selinux and only has access to the workspace i am working on.

I got that part working, but got stumped with this plugin as there seems to be no way to connect to like localhost:4096 and authenticate.

Also kept looking for the opencode binary... can this work without the opencode binary if the opencode server is remote?

[nickjvandyke]

@dngray setting vim.g.opencode_opts.server.port = 4096 will try http://localhost:4096, assuming that host port is mapped to your podman container. It should work w/o authentication? So you still get the sandboxing the meantime.

Also kept looking for the opencode binary... can this work without the opencode binary if the opencode server is remote?

When port is set (per above) the plugin only checks that, and doesn't attempt to discover opencode processes. I plan to retain that behavior in this issue unless I find a reason not to 🙂