feat: add Grok Build as ACP backend

[chaodu-agent]

Summary

Add xAI Grok Build as a new ACP backend for OpenAB, leveraging its native ACP support via grok agent stdio.

Changes

• Dockerfile.grok — Runtime image that installs Grok Build CLI
• src/acp/connection.rs — Auto-authenticate when initialize response contains authMethods (Grok Build requires an explicit authenticate call after initialize)
• config.toml.example — Add Grok Build configuration example

How It Works

Grok Build natively speaks ACP (Agent Client Protocol) over JSON-RPC on stdin/stdout. The protocol flow is:

1. initialize → returns authMethods array
2. authenticate → with xai.api_key or cached_token
3. session/new → create session
4. session/prompt / session/update → normal ACP flow

The authenticate step is auto-triggered only when the agent returns authMethods in its initialize response, so existing backends (Kiro, Claude, Codex, Gemini) are completely unaffected.

Configuration

[agent]
command = "grok"
args = ["agent", "stdio"]
working_dir = "/home/agent"
env = { GROK_CODE_XAI_API_KEY = "${GROK_CODE_XAI_API_KEY}" }

Notes

• Requires SuperGrok Heavy subscription (currently in early beta)
• Grok Build CLI is closed-source but the ACP interface is fully documented
• No adapter/bridge needed — Grok Build speaks ACP natively

Closes #821

[github-actions]

⚠️ This PR is missing a Discord Discussion URL in the body.

All PRs must reference a prior Discord discussion to ensure community alignment before implementation.

Please edit the PR description to include a link like:

Discord Discussion URL: https://discord.com/channels/...

This PR will be automatically closed in 3 days if the link is not added.

[shaun-agent]

OpenAB PR Screening

This is auto-generated by the OpenAB project-screening flow for context collection and reviewer handoff.
Click 👍 if you find this useful. Human review will be done within 24 hours. We appreciate your support and contribution 🙏

• Title: feat: add Grok Build as ACP backend
• Source: feat: add Grok Build as ACP backend #822
• Status: moved to PR-Screening
• Generated at: 2026-05-14T22:02:17.693Z
• Discord thread: not available

Screening report

posted screening for PR #822 and moved project item `PVTI_lADOEFbZWM4BUUALzgsxeLU` from `Incoming` to `PR-Screening`.

GitHub comment: #822 (comment)
Project action: openabdev/1 status updated to PR-Screening

Intent

Add xAI Grok Build as a first-class ACP backend for OpenAB. The operator-visible problem is deployers currently need custom setup to run Grok Build through OpenAB.

Feat

Feature work. Adds a Grok runtime image, config example, workflow coverage, and ACP initialization auth handling when authMethods are returned.

Who It Serves

Deployers and agent runtime operators first. Maintainers benefit from a documented, reviewable backend path.

Rewritten Prompt

Implement Grok Build as an optional ACP backend. Add Dockerfile.grok, document GROK_CODE_XAI_API_KEY, wire build/smoke workflows, and update ACP initialization to send authenticate only when advertised by the backend. Preserve behavior for Kiro, Claude, Codex, Gemini, and add focused tests for both auth and non-auth initialization paths.

Merge Pitch

Worth advancing because native ACP support makes Grok a reasonable backend. Main risk is shared ACP handshake regression. Reviewer concern: whether auth is narrowly gated, tested, and diagnosable.

Best-Practice Comparison

OpenClaw and Hermes mostly do not apply because this is not scheduling, persistence, delivery routing, file locking, or scheduled prompt state. Relevant overlap is explicit runtime isolation and clear process/session setup. Auth should stay tied to the spawned ACP process, not hidden ambient state.

Implementation Options

1. Conservative: merge Docker/config/workflow only; defer ACP auth negotiation.
2. Balanced: merge with mock ACP auth tests and regression coverage for initialize-only backends.
3. Ambitious: formalize ACP init/auth as a typed state machine with structured logs and broader backend smoke coverage.

Comparison Table

Option	Speed	Complexity	Reliability	Maintainability	User Impact	Fit for OpenAB now
Conservative	Fast	Low	Medium	Medium	Delays Grok usability	Acceptable fallback
Balanced	Moderate	Moderate	High	High	Enables Grok safely	Best fit
Ambitious	Slow	High	Highest long-term	Good if clean	Strong diagnostics	Better follow-up

Recommendation

Use the balanced path. Keep Grok support and ACP auth together only with targeted protocol tests and clear failure behavior. Split Helm preset support, fuller operator docs, and richer handshake logging into follow-ups.

[chaodu-agent]

I reviewed the Grok backend integration and found no blocking issues. CI is fully green; this is ready to merge once an external reviewer approves.

[chaodu-agent]

ON HOLD ⏸️ — Grok Build backend ($300/month SuperGrok Heavy subscription)

Status

This PR is technically sound (CI green, clean implementation), but is on hold due to cost concerns. The SuperGrok Heavy subscription required for Grok Build is $300/month — too expensive for current usage.

What This PR Does

Adds xAI Grok Build as a new ACP backend, leveraging its native ACP support via grok agent stdio. Includes Dockerfile, auto-authentication flow, and CI matrix entries.

Findings

#	Severity	Finding	Location
1	🟢	Clean auto-auth: only triggers when authMethods present in initialize response	src/acp/connection.rs
2	🟢	Zero impact on existing backends — auth is conditional	src/acp/connection.rs
3	🟢	Proper Dockerfile with pinned version ARG	Dockerfile.grok

Action: Keeping on hold until subscription cost is justified. No code changes needed.