Grok 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.

Grok is one of those six. The list of providers this library plans to support is drawn from that set, because it is evidence of which CLIs people actually want driven from a plugin, rather than a guess about which ones matter.

What is known

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

The survey recorded the send parameters for two channels in detail — Claude’s sessionId, disableThinking, agentPrompt against Codex’s threadId, baseUrl, apiKey, serviceTier — and Grok was not among them.

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.
Whether it has auth and mcp subcommands, and in what shape.

No inference is offered here in place of investigation. When this CLI is attached, the facts will come from running it.

What attaching it would contribute

AbstractAdapter is five members and stays that way until a second adapter forces the question. Whichever CLI arrives second is the one that decides the shape — and the ones after it are what confirm the shape was not fitted to a single pair.

The porting order does not change per provider:

Port the adapter accurately, matching the CLI’s real behaviour.
Note every place the existing contract had to be worked around.
Extract the common shape.
Only then widen AbstractAdapter.

Where to go next

Writing a provider — what attaching a CLI involves.
Codex provider — the planned provider with the most established about it.
Roadmap — where this sits in the order of work.