feat: add Grok Build (xAI) as agent provider

[canyugs]

Discord Discussion URL

Internal thread on the openab-testing Discord (channel 1495121978007228466, thread 1505232450471596096) — discussed "should OpenAB ship a pure xAI variant alongside Hermes" on 2026-05-16. Summary: Hermes already supports xAI Grok OAuth, but it pulls in the entire Nous gateway, requires loopback OAuth (kubectl port-forward / ECS curl-the-callback), and adds a second supply-chain dependency. Now that xAI's official grok CLI (Grok Build, GA 2026-05-14) ships native ACP and supports headless API-key / device-code auth, a dedicated Dockerfile is simpler for users who only want Grok.

1. What problem does this solve?

OAB users who want to run xAI Grok currently have to deploy Dockerfile.hermes and complete the loopback-OAuth flow (hermes auth add xai-oauth). That flow needs port-forwarding into the pod or an ECS curl-the-callback workaround, both of which are documented in docs/hermes.md but are non-obvious operations and pull in 30+ unused providers.

xAI released Grok Build on 2026-05-14 — an official coding-agent CLI distributed as a single static binary with native ACP (grok agent stdio). It supports three headless auth modes:

1. GROK_CODE_XAI_API_KEY env var (pay-per-token API)
2. Device-code OAuth (SuperGrok subscription) — no port-forward
3. GROK_DEPLOYMENT_KEY env var (enterprise managed config)

This PR adds Dockerfile.grok so users who only need Grok can deploy it without the Nous gateway layer.

No issue filed yet — happy to open one if maintainers prefer.

2. At a Glance

Hermes path (existing):
  OAB ──ACP──> hermes-acp ──HTTPS──> Nous gateway ──HTTPS──> xAI

Grok path (this PR):
  OAB ──ACP──> grok agent stdio ──HTTPS──> xAI

3. Prior Art & Industry Research

• OpenClaw: gateway-style aggregator; same model-routing pattern as Hermes. Doesn't ship a per-provider native-ACP variant.
• Hermes Agent (Dockerfile.hermes, PR feat: add Hermes Agent as agent provider #824): existing OAB integration. This PR coexists with it — see the comparison table in docs/grok.md. Hermes wins on multi-provider switching and fallback chains; Grok wins on supply-chain surface and headless auth simplicity.
• Codex CLI (Dockerfile.codex): closest analog inside the repo — also an official-vendor CLI with ACP support (via @zed-industries/codex-acp wrapper). Grok Build ships ACP in-binary so no wrapper is needed.

4. Proposed Solution

Mirror the existing per-agent Dockerfile pattern. Four touchpoints:

1. Dockerfile.grok — debian:bookworm-slim base. Pinned GROK_VERSION=0.1.211 with separate SHA256s for amd64 and arm64. Binary pulled directly from https://storage.googleapis.com/grok-build-public-artifacts/cli/ (the same source https://x.ai/cli/install.sh resolves to) so the install script's PATH/shell-config side-effects are skipped in the container.
2. docs/grok.md — Docker build / Helm install / three auth flows / credential persistence / model selection / comparison with Dockerfile.hermes.
3. config.toml.example — agent block placed immediately after the hermes one.
4. .github/workflows/build.yml — grok variant added to build-image, merge-manifests, and promote-stable matrices.

ACP invocation grok agent stdio was verified against the 0.1.211 binary's --help output (subcommand tree includes agent → stdio | headless | serve | leader).

5. Why This Approach

• Pinning the binary, not the installer: Dockerfile.hermes pins NousResearch's install.sh by commit + SHA256. The xAI install script doesn't expose a versioned URL, but the GCS-hosted binary itself does. Pinning the binary directly is one fewer indirection and verifies what actually runs.
• No wrapper: Grok Build implements ACP natively, so unlike Dockerfile.codex we don't need a separate *-acp package on top.
• Three auth options up front: covers the three deployment shapes maintainers have asked about — pure-API-key CI bots, SuperGrok subscription via device-code, and enterprise deployment keys.

Known limitations:

• Helm chart values for agents.grok.* not added yet — docs/grok.md documents --set flags so users can deploy today, but a chart-side first-class entry is a follow-up PR.
• Image size: full grok binary is ~110 MB (amd64). Comparable to other agent variants.

6. Alternatives Considered

• Extend Dockerfile.hermes instead of new file: rejected. Hermes provides value as a multi-provider gateway; conflating it with a single-provider variant erases the distinction users currently rely on.
• Use https://x.ai/cli/install.sh directly in the Dockerfile (à la Hermes): rejected. The script modifies ~/.bashrc, writes ~/.grok/config.toml, and fetches managed config from a proxy URL — useful for interactive installs, noise in a container.
• @superagent-ai/grok-cli community wrapper: rejected. It's a third-party project on top of the xAI API; defeats the point of preferring the official surface.

7. Validation

• Build script reasoning: grok agent stdio confirmed against 0.1.211 --help.
• SHA256s computed locally: 9245f9c9... (amd64), b283cb72... (arm64) — both downloaded from the GCS bucket and sha256sum'd.
• Install URL probed: https://x.ai/cli/install.sh returns HTTP 200 (cross-checked the install script's own GCS fallback URL to derive the artifact path).
• Channel pointer verified: https://x.ai/cli/stable → 0.1.211.
• docker build -f Dockerfile.grok: not yet run — opening as Draft for this reason; will run before marking ready.
• End-to-end ACP smoke: planned via openab-testing once the image is on GHCR.
• Helm chart values: deferred to follow-up PR.

8. Follow-ups

• Helm chart agents.grok.* values + templates (follow-up PR).
• Smoke-test image in openab-testing project once GHCR publishes.
• Add grok to docker-smoke-test.yml once the basic ACP handshake is validated.

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

[canyugs]

Mis-targeted upstream — re-opening on the canyugs fork. Sorry for the noise.