feat: add Grok Build CLI as supported agent

[canyugs]

What problem does this solve?

OpenAB is adding Grok Build as one of its supported CLIs through the official grok agent stdio interface. However, for a new CLI to be truly usable in production environments, the Helm chart configuration must be complete and consistent with other supported agents.

Currently, agents such as hermes, cursor, claude, codex, gemini, and opencode all provide clear, ready-to-use configuration examples in values.yaml, along with authentication instructions in NOTES.txt. This allows users to easily enable them via Helm.

Grok was missing this piece. As a result, Helm users had to manually construct long and error-prone --set commands, making the experience inconsistent and incomplete.

This PR adds the necessary Helm configuration example for Grok, completing its support as a first-class CLI option in OpenAB.

At a Glance

User experience comparison when deploying Grok as a CLI:

Before (Missing Helm configuration example):

Helm user wants to deploy Grok as an agent
    │
    └── must manually write long --set commands
        (no grok example in values.yaml)

After (This PR):

Helm user wants to deploy Grok as an agent
    │
    └── can directly copy the grok example from values.yaml
        + see login instructions in NOTES.txt
        (same experience as hermes, cursor, claude...)

Actual connection after Helm deployment:

OpenAB (deployed via Helm)
    │
    │ ACP (stdio JSON-RPC)
    ▼
grok agent stdio (running in the same pod)
    │
    │ HTTPS (device-auth or API Key)
    ▼
xAI (Grok models)

Prior Art & Industry Research

Hermes Agent (PR #824):
The most relevant reference. Hermes was introduced with full documentation, including a detailed commented block in values.yaml and login instructions in NOTES.txt. This has become the standard approach when adding new CLI/agent support in OpenAB.

Other agents:
Cursor, Claude, Codex, Gemini, and OpenCode all follow the same pattern, providing clear Helm examples so users can adopt them easily.

OpenClaw:
Takes a different gateway-style approach and does not maintain per-CLI Helm examples in the same way, making it a less direct reference.

Proposed Solution

• Add a complete, commented # grok: configuration block in charts/openab/values.yaml.
• Add the corresponding Grok authentication instruction in charts/openab/templates/NOTES.txt.

The Helm templates themselves did not require changes, as they already support arbitrary agents generically.

Why this approach?

To establish Grok as a properly supported CLI in OpenAB, it must offer the same level of Helm usability as other agents. Providing a clear configuration example is the minimal and most consistent way to achieve this.

Alternatives Considered

• Only documenting usage through --set flags in the documentation — Rejected. This would result in a significantly worse experience for Helm users compared to other CLIs.
• Enabling Grok by default in the chart — Rejected. Following the existing convention of keeping new agents commented out.

Validation

Helm chart validation:

• helm template test charts/openab renders successfully.
• helm template test charts/openab --set agents.kiro.enabled=false --set agents.grok.enabled=true produces a valid Grok deployment.

Manual testing:

• Built Dockerfile.grok locally.
• Ran a full test with Discord + grok agent stdio.
• Completed grok login --device-auth inside the container using a real SuperGrok subscription.
• Verified through the Discord API that the bot could successfully interact with Grok.

Follow-ups

None. This PR completes the Helm configuration support for Grok as a CLI in OpenAB.

[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(helm): add grok agent example to values.yaml and NOTES.txt
• Source: feat: add Grok Build CLI as supported agent #831
• Status: moved to PR-Screening
• Generated at: 2026-05-16T17:42:33.855Z
• Discord thread: not available

Screening report

posted screening comment and moved the project item to `PR-Screening`.

GitHub comment: #831 (comment)
Project action: https://github.com/orgs/openabdev/projects/1 (PVTI_lADOEFbZWM4BUUALzgs7E4w now PR-Screening)

Intent

PR #831 makes Grok a complete Helm-deployable CLI option for OpenAB.

Feat

Feature work: Helm values example, NOTES auth guidance, Dockerfile, CI coverage, config example, and docs.

Who It Serves

Deployers and agent runtime operators using OpenAB via Helm.

Rewritten Prompt

Add Grok as a documented, opt-in Helm agent example following existing agent conventions. Keep it disabled by default, document grok agent stdio, authentication, runtime support, and validate Helm rendering.

Merge Pitch

Worth advancing. Risk is moderate: mostly additive docs/config, but Dockerfile and workflow changes need focused review.

Best-Practice Comparison

Hermes Agent is the relevant comparison: this follows the same per-agent Helm/docs pattern. OpenClaw scheduling/delivery practices do not directly apply here.

Implementation Options

1. Conservative: split to Helm/NOTES only.
2. Balanced: keep as Grok enablement bundle with focused Docker/CI review.
3. Ambitious: turn this into a formal new-agent onboarding standard.

Comparison Table

Included in the GitHub comment.

Recommendation

Use the balanced path. Advance to PR-Screening, then have Masami or Pahud review Dockerfile, workflow changes, and Helm rendering.

[canyugs]

Thanks for the review!

1. NOTES.txt
   Added the note for bot/CI deployments as suggested:

   For bot/CI deployments, prefer setting GROK_CODE_XAI_API_KEY via secretEnv instead of interactive device-auth login. See docs/grok.md for all authentication options.

2. /usr/local/bin/agent symlink
   Removed the symlink. It was originally added to match the official xAI install script behavior, but it is not referenced by OpenAB, the Helm chart, or CI. The generic name could also cause confusion in multi-agent setups.

Both changes have been committed and pushed. Thanks again for the review!

[chaodu-agent]

LGTM ✅ — All previous findings addressed. Clean integration following established patterns.

What This PR Does

Adds Grok Build CLI as a first-class agent in OpenAB: Dockerfile, Helm values/NOTES, CI pipelines, config example, and full documentation.

How It Works

• Dockerfile.grok downloads a pinned + SHA256-verified grok binary from xAI's public GCS bucket (multi-arch: amd64/arm64).
• grok agent stdio speaks ACP natively — no wrapper needed.
• Three auth methods documented: API key (env var), device-code OAuth, enterprise deployment key.
• Helm values block is commented out (consistent with other agents), NOTES.txt shows both interactive and API-key auth guidance.

Findings

#	Severity	Finding	Location
1	🟢	Previous 🟡 resolved: unused agent symlink removed	c3de45cd
2	🟢	Previous 🟡 resolved: NOTES.txt now mentions API-key for bot deployments	2e5b79a3
3	🟢	Excellent supply-chain hygiene: pinned version + SHA256 checksum verification	Dockerfile.grok:21-35
4	🟢	Comprehensive documentation covering 3 auth methods, model selection, persistence, and comparison with hermes	docs/grok.md
5	🟢	Consistent with established agent onboarding pattern (build matrix, smoke test, values example, NOTES auth hint)	—

Baseline Check

• PR opened: 2026-05-16
• Main already has: No grok-related content
• Net-new value: Complete Grok Build CLI integration (Dockerfile, Helm, CI, docs)

What's Good (🟢)

• SHA256 checksum verification prevents supply-chain tampering
• Multi-arch support (amd64 + arm64) with per-arch checksums
• Documentation is thorough and well-structured with security callouts
• Follows the exact same pattern as other agents (hermes, cursor, claude, codex)
• CI smoke test confirmed working: grok agent stdio responds to ACP initialize even without auth
• Responsive to review feedback — both findings fixed promptly in separate clean commits

Review Team

Reviewed by: 超渡法師 (coordinator), 普渡法師, 擺渡法師, 口渡法師

• 擺渡法師 verified against xAI official Build docs and tested pinned grok 0.1.211 CLI behavior
• CI smoke-test green