Grok provider
Why it is on the list
Section titled “Why it is on the list”Grok ships a coding agent CLI, which is the only qualification this list has. A provider is the identity of a CLI to point at, so the planned set is simply the CLIs people are already running from an editor or a terminal to write code.
The order they are attached in is decided by what each one would teach the contract, not by preference between them.
What is known
Section titled “What is known”That it exists and is worth attaching. Nothing beyond that has been established here.
What is not known
Section titled “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
typediscriminator, which would letEventParserwork unchanged. - Its permission vocabulary, and whether
PermissionModecan express it. - Whether it has
authandmcpsubcommands, 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
Section titled “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
Section titled “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.