OpenCode provider

Why it is on the list

The largest competing JetBrains plugin, zhukunpenglinyutong/jetbrains-cc-gui (5,315 stars), attaches six CLI channels under ai-bridge/channels/ — claude, codex, grok, kimi, opencode, pi — with no common contract between them.

OpenCode is one of those six. Its presence there is the reason it is planned here.

What is known

That it is one of the six channels, and nothing more.

The survey recorded send parameters in detail for Claude and Codex only. OpenCode’s were not among them, so this page has no verified facts about the CLI’s interface to report.

What is not known

Everything else. Not yet investigated:

The command name and how a conversation is identified.
Which flags make it a controllable two-way stream.
Whether its output is NDJSON with a type discriminator, which would let EventParser work unchanged.
Its permission vocabulary, and whether PermissionMode can express it without a new member.
Whether it has auth and mcp subcommands, and in what shape.

Where a fact is missing here, it is missing because it has not been checked — not because it was judged unimportant.

What attaching it would contribute

Every port applies pressure to the same two places, and both are findings to raise rather than things to work around:

Auth/ and Mcp/ are currently Claude-shaped. They run claude auth status --json and claude mcp list and parse what those print. Constructed with a provider’s name, they will run against another CLI and produce nothing useful if it spells its subcommands differently.
PermissionMode is a closed set. Its constructor is private precisely so no mode can appear that other adapters cannot spell. A CLI with a concept the set cannot express is evidence that the shared vocabulary needs reshaping, and should be discussed rather than worked around.

Where to go next

Writing a provider — what attaching a CLI involves.
Abstract provider — the contract as it stands.
Roadmap — where this sits in the order of work.