[FEATURE]: ACP over WebSocket for remote/network access

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

Expose the Agent Client Protocol (ACP) over WebSocket so editors and clients can use OpenCode from another host on the network (e.g. remote dev machine, browser), not only via stdio.

Proposed solution

Add a WebSocket endpoint at /acp on the existing OpenCode server (same port as REST API, e.g. 4096).
Use the server’s startup directory as context; allow override via query/header.
Add CLI command opencode acp-websocket to start the server and advertise the ACP WebSocket URL.

Protocol stays JSON-RPC 2.0 newline-delimited; only the transport changes from stdio to WebSocket.

This issue might be a duplicate of or closely related to existing issues. Please check:

[FEATURE]: ACP can call a specified opencode server #12853: ACP can call a specified opencode server — addresses multi-editor contexts where ACP connects to a single instance
[FEATURE]: Better support remote/server-client use-cases from the CLI #8890: Better support remote/server-client use-cases from the CLI — includes distributed architecture goals with ACP
feat(desktop): Auto-start web server mirror for remote access #11997: Auto-start web server mirror for remote access — addresses remote access needs via TCP proxy and web UI (different approach than WebSocket ACP)

Please review these issues to understand any overlapping goals or dependencies before proceeding.

This issue might be a duplicate of or closely related to existing issues. Please check:

[FEATURE]: ACP can call a specified opencode server #12853: ACP can call a specified opencode server — addresses multi-editor contexts where ACP connects to a single instance

[FEATURE]: Better support remote/server-client use-cases from the CLI #8890: Better support remote/server-client use-cases from the CLI — includes distributed architecture goals with ACP

feat(desktop): Auto-start web server mirror for remote access #11997: Auto-start web server mirror for remote access — addresses remote access needs via TCP proxy and web UI (different approach than WebSocket ACP)

Please review these issues to understand any overlapping goals or dependencies before proceeding.

Thanks for flagging these. I’ve checked the related issues:
#12853 (ACP call specified server) and #8890 (remote/server–client CLI) are about the client side: the ACP client (e.g. opencode acp) connecting to an existing OpenCode server (e.g. via --attach or a server URL).
#11997 is about remote web UI via a TCP proxy for the app, not ACP.
This PR adds the server side: a WebSocket endpoint at /acp so that an already-running OpenCode server exposes ACP over the network. That enables:
Any ACP client (editor, script, or a future opencode acp --url ws://host:4096/acp) to connect to that server.
The use case in #12853 (e.g. “single opencode instance, multi-editor”) once clients support connecting to a WebSocket URL.
So this is the missing piece for “ACP can call a specified opencode server”: the server must first expose ACP over WebSocket, which is what this PR does.

I came looking for something like this today.
My use case is having OpenClaw spin up an OpenCode instance via ACPX. I'd love to be able to attach to the same instance to see what's happening and directly talk to opencode when needed.

@LydiaCai1203

you can use monkeycode-ai, they use opencode, and support ws, and support free model, https://monkeycode-ai.com/?ic=019b039d-6e93-7848-bf41-3d8765291f3c this is my invite link

This is a Chinese web ui. English language is not available. Why ? @LydiaCai1203

+1 on this from a workflow perspective

Been using opencode acp as a sub-process for task coordination and the event stream is a useful tool call updates, plan events, usage per session. The only gap is each spawn boots fresh (~3-5s overhead) and sessions don't share context across spawns.

PR #13385's approach of putting /acp as a WS endpoint on the existing server would solve that cleanly. One instance, multiple clients, shared session pool. Would love to see this revived.

There is an open v2-Draft on Streamable HTTP & WebSocket Transport for ACP since 3 weeks and discussions on this since a few months.
A first implementation can be found in Goose: aaif-goose/goose#8605 which is supposed to be the reference, part of 1.34.0 and the foundation of Goose 2.0 with ACP as its default interface. This is currently phase 2 out of 4. Details on this steps can be found in this meta-issue and might be worth a look.

I have a related local-editor use case and wanted to ask which direction maintainers would prefer before attempting a PR.

Use case: I run a long-lived opencode web/serve backend on :4096 and want editor ACP integrations, specifically Zed's external agent support, to reuse that backend instead of each opencode acp spawn creating a fresh server.

A smaller alternative to a full /acp WebSocket endpoint might be:

opencode acp --attach http://127.0.0.1:4096 --dir /path/to/project

This would keep the existing ACP stdio transport for editors, but build the internal SDK client against an existing server, similar to the precedent in opencode run --attach and opencode attach.

Would that be an acceptable first step, or would you prefer this only happen through the broader ACP-over-HTTP/WebSocket transport work?

Should someone have time to do it, this is probably also implementable as a standalone proxy:

NPM package mcp-proxy turns a stdio MCP into StreamableHTTP or SSE endpoint: https://www.npmjs.com/package/mcp-proxy
Python project mcp-proxy turns a stdio MCP into StreamableHTTP or SSE endpoint, or vice versa: https://github.com/sparfenyuk/mcp-proxy
NPM package mcp-remote turns a StreamableHTTP or SSE endpoint into a stdio pipe: https://www.npmjs.com/package/mcp-remote

To save folks time: Because ACP is distinct enough from MCP, npx mcp-proxy --port 1235 -- ~/opencode.sh acp did not work for me. I haven't tried any other implementation at this time.

To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Navigation Menu

Repository navigation

[FEATURE]: ACP over WebSocket for remote/network access #13388

Feature hasn't been suggested before.

Describe the enhancement you want to request

Summary

Proposed solution

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[FEATURE]: ACP over WebSocket for remote/network access #13388

Description

Feature hasn't been suggested before.

Describe the enhancement you want to request

Summary

Proposed solution

Activity

github-actions commented on Feb 12, 2026

doxycomp commented on Feb 12, 2026

GollyJer commented on Apr 11, 2026

cmoulliard commented on May 4, 2026

ReqX commented on May 4, 2026

jhgoebbert commented on May 14, 2026

praveng commented on May 25, 2026

ivucica commented on Jul 21, 2026

github-actions commented on Sep 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions