Repository navigation
[FEATURE]: OpenCode Remote Control #47692
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
In corporate environments, developers run OpenCode on dev machines but may need to access it from a browser on a different workstation, behind corporate SSO.
opencode serve already exposes the full API over HTTP, and the web UI embedding API (AppInterface, PlatformProvider, ServerConnection) is well-designed for third-party consumers. These two together make remote access feasible today.
Similar to how Claude Code Remote Control lets users continue local sessions from any browser or mobile device, OpenCode could support a similar workflow — but routed through a self-hosted gateway with corporate OIDC auth.
What's missing is the glue:
- A way to discover and route to multiple dev machines from a single URL
- Corporate OIDC authentication in the browser flow
- A web entry point that wraps the OpenCode UI with user context
How it would work:
- Developer runs
opencode remote-controlon their dev machine — it authenticates via OIDC, startsopencode serve, and registers itself with a central gateway - Developer opens the gateway's web UI from any browser — authenticates via OIDC, sees their live sessions listed
- Clicking a session loads the full OpenCode web UI (embedded via
AppInterface), proxied through the gateway to the dev machine
Related: #45346 (remote server sessions as tabs) — the gateway would solve the discovery and routing layer that issue assumes is already in place.
I've been building a prototype and have it working end-to-end. The web entry point follows the same embedding pattern as packages/desktop. Would love to discuss whether this is something the project would want to support — open to a PR or a different approach.
Activity
github-actions commentedon Sep 6, 2026
This issue might be a duplicate of existing issues. Please check:
opencode join— hub-managed node fleet with centralized session discovery #44760: Very similar concept — hub-managed node fleet with centralized session discovery and routing (overlaps heavily with the gateway + multi-machine registration idea here)These may be worth reviewing before proceeding with a PR to avoid duplicated effort or conflicting designs.
ibaoger commentedon Sep 22, 2026
Your proposal is very close to a workflow we are exploring with CPJ, an independent third-party control surface for supported local OpenCode sessions. CPJ is not built by the OpenCode team and is not affiliated with OpenCode.
We keep the OpenCode process on the user’s Windows or macOS machine and use a separate phone/web surface to view events and send follow-up input when the session exposes that capability. We are interested in the same boundaries your proposal calls out: session identity, multi-machine routing, event streaming, approval prompts, and what a gateway should or should not persist. This is not a claim of official integration or compatibility.
On our side, credentials and the full source tree stay on the execution device. Prompts, terminal output, titles, paths, and code snippets appearing in output may cross the encrypted relay. Recovery and stop actions are capability-dependent, and an accepted request is not reported as completed.
If useful, I can share a short, reversible comparison using a redacted repository and one approved directory, without submitting code or attachments. Product page: https://choupijiang.istarlit.com/ . I’ll follow the project’s contribution guidance and would be glad to compare this with the gateway/
opencode servedirection here.opencodejr commentedon Oct 28, 2026
Thanks for the detailed write-up and for building a prototype, @rophy! To restate: you'd like a self-hosted gateway that dev machines register with (for example via an
opencode remote-controlcommand). Users would sign in with corporate OIDC SSO in the browser, see their live sessions across machines, and open the full web UI proxied through the gateway to the right machine.Since you opened this, v2 has added a related built-in option:
opencode pairwith remote access through OpenTunnel (#53837, #55306). It doesn't cover a self-hosted gateway, corporate OIDC or finding sessions across several machines, so your request still adds something new.Some later issues ask for overlapping things and may be worth looking at for your design:
opencode servebehind OIDC SSOservedirectlyMaintainers will consider the request and how it should fit with the existing pairing and remote access work. It might help to say briefly which parts of your prototype would need changes in OpenCode itself and which could live entirely in a separate gateway.
rophy commentedon Oct 28, 2026
Thanks. The prototype is now usable: https://github.com/rophy/opencode-rc (MIT). It has a gateway with corporate OIDC, a CLI that tunnels a dev machine's
opencode serve, a web UI embedding OpenCode's app (1.x and 2.x), mobile apps and a Helm chart.It runs on an unmodified
opencode serve. Discovery, routing and OIDC stay in the gateway. What would help from OpenCode:AppInterface,PlatformProvider,ServerConnection). Today we buildpackages/appfrom a pinned submodule for each release.#59248 is a different approach (the client does OIDC itself). Both could share (2).