OpenCode CLI adds ACP server support

OpenCode’s CLI now includes an ACP server, plus commands for TUI, headless web access, sessions, plugins, and GitHub automation.

OpenCode has turned its command line into a full control surface for agent workflows. The docs show a CLI that can launch the TUI by default, run one-off prompts, start a headless server, and expose an ACP server over stdin/stdout using nd-JSON.

That matters because the CLI is no longer just a shortcut for power users. It is the main entry point for local automation, remote access, GitHub repo actions, and protocol integration with other tools.

The CLI is the product’s control plane

OpenCode’s CLI is built around a simple idea: the same app should work in a terminal, over HTTP, and through protocol bridges. If you run opencode with no arguments, you get the TUI. If you pass a command, you can automate work, inspect sessions, or launch a server for another client to connect to.

That design makes the CLI more useful than a thin wrapper around a chat interface. It is the layer where models, agents, sessions, auth, and transport choices all meet.

The docs break the CLI into a few major areas:

• tui for the interactive terminal UI
• run for scripted prompts and JSON output
• serve and web for headless server access
• acp for protocol-based integration
• session, stats, export, and import for history and telemetry

That spread tells you what OpenCode is optimizing for. It is not trying to keep users inside one interface. It is trying to let the same backend power several workflows without making you change tools every time you switch context.

ACP support is the most interesting addition

The new ACP command is the part worth watching closely. The docs say opencode acp starts an ACP server that communicates via stdin/stdout using nd-JSON. In practice, that means OpenCode can speak to other clients in a structured way without forcing everything through the TUI or a browser tab.

That opens the door to tighter integrations with editors, automation scripts, and agent runners. It also fits the direction the rest of the CLI points toward: a backend that can be driven from many front ends, not a single app with a single opinionated UI.

“This command starts an ACP server that communicates via stdin/stdout using nd-JSON.”

The quote is straight from the OpenCode CLI docs, and it matters because it tells you exactly how the protocol boundary works. stdin/stdout transport is simple, portable, and easy to embed in tooling that already knows how to talk to local processes.

OpenCode also exposes related server modes through serve and web. The first gives you API access without the TUI, and the second adds a browser interface on top of the same backend. ACP is the third path, aimed at protocol-aware clients.

• opencode serve starts an HTTP server for API access
• opencode web starts an HTTP server and opens a browser UI
• opencode acp starts a protocol server over stdin/stdout
• opencode run --attach can connect to a running server to avoid repeated cold starts

OpenCode is built for real workflows, not demo commands

The rest of the CLI shows how much attention OpenCode gives to practical usage. You can manage agents with opencode agent, authenticate providers with opencode auth, inspect available models with opencode models, and install GitHub automation with opencode github install.

There is also a clear bias toward reproducibility. Session export and import are built in, and opencode stats can show token usage and cost data. For teams that care about auditability, those are the commands that matter after the novelty wears off.

Here are a few of the more concrete options the docs expose:

• opencode models --refresh updates the cached provider list
• opencode session list --format json returns session data in machine-readable form
• opencode export --sanitize redacts sensitive transcript and file data
• opencode uninstall --keep-config removes the app while keeping configuration files

That mix says something important about the project’s audience. OpenCode is not only for people who want to chat with a model in the terminal. It is for developers who want to wire model access into scripts, server processes, GitHub Actions, and local tooling without rewriting their workflow from scratch.

How OpenCode compares with other CLI-first AI tools

Compared with many AI coding tools, OpenCode gives you more transport options in one package. Some tools focus on an editor plugin or a browser app. OpenCode gives you a terminal UI, a non-interactive runner, a headless HTTP server, and now an ACP server.

That matters because different jobs need different interfaces. A one-off question is fine in run. A long debugging session fits the TUI. A remote integration wants serve or web. A protocol client wants acp. OpenCode is building for all four instead of forcing a single path.

• TUI: best for interactive work in one terminal
• run: best for scripts and CI-like automation
• serve/web: best for remote access and browser use
• acp: best for clients that want a process protocol

The other useful comparison is around state. Commands like session list, session delete, export, and import make session history a first-class feature. That is a strong signal that OpenCode expects people to move between terminals, servers, and shared links while keeping continuity.

If you want a broader picture of how OpenCode is positioning itself, our earlier coverage of its workflow features is worth a look: OpenCode agent workflows and session tools.

What to watch next

The ACP server is the detail that could matter most over time, because protocol support usually decides whether a developer tool becomes part of a larger ecosystem or stays isolated. If OpenCode keeps this path polished, it can slot into more local automation setups and more client apps without requiring custom glue each time.

The practical takeaway is simple: if you are already using OpenCode, the CLI is now worth learning as a system, not as a list of commands. If you are evaluating it, start with run for automation, then test serve or acp depending on whether you want HTTP or process-based integration.

The next question is whether third-party clients adopt ACP as quickly as OpenCode is shipping support for it. If they do, the CLI will become more than a local utility. It will be the bridge between OpenCode and the rest of your toolchain.