feat(harness): add Grok Build CLI provider - #861
Open
storyicon wants to merge 1 commit into
Open
Conversation
Introduce a first-class harness provider for the local Grok Build CLI so AgentField can drive Grok headless sessions the same way it drives Codex, OpenCode, Gemini, and Claude Code. The provider wraps the Grok CLI with a PTY (via script) because plain pipes currently fail with "Device not configured", feeds prompts through --prompt-file to avoid argv limits, and normalizes missing token usage to zero so metrics aggregation does not crash on incomplete usage objects.
7 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds a first-class Grok Build CLI harness provider so AgentField can orchestrate local
grokheadless sessions with the same provider surface as Codex, OpenCode, Gemini, and Claude Code.The goal is to make Grok a peer runtime for multi-turn coding-agent work (read/write/edit/bash tool loops) without requiring callers to shell out ad hoc or invent a parallel execution path.
Motivation
AgentField already standardizes coding-agent execution behind
HarnessProvider+build_provider(). Operators who use Grok Build CLI locally currently cannot plug that binary into the harness stack:provider="grok"registrationWithout this, multi-agent frameworks built on AgentField (for example SWE-AF) cannot select Grok as a first-class runtime the way they select Codex or Claude Code.
Design considerations
1. Provider shape matches existing CLI providers
GrokProviderfollows the same contract asCodexProvider/OpenCodeProvider:ensure_cli_available("grok", bin_path)run_cliwith optional env / cwdRawResult(is_error=True, failure_type=…)RawResult.resultThis keeps the runner, schema pipeline, and retry logic provider-agnostic.
2. PTY wrapping is required for Grok today
Plain pipe attachment causes Grok to fail with
Device not configured (os error 6). Whenscript(1)is available, the provider runs:scriptallocates a PTY while still delivering agent JSON on stdout. Ifscriptis missing, the provider falls back to a directgrokinvocation (same flags) so environments withoutscriptare not hard-broken, but PTY-capable hosts remain the recommended path.3. Prompt delivery via
--prompt-fileLong AgentField prompts exceed practical argv limits. The provider always writes the prompt to a temporary file and passes
--prompt-file, then unlinks the file infinally.4. Permission mode mapping for unattended runs
Harness executions are unattended. The provider maps common AgentField permission modes onto Grok’s
--permission-modevalues and defaults to non-interactive approvals (bypassPermissions/acceptEdits/--always-approve) so coding loops do not block on TTY prompts.5. Metrics robustness (token fields may be absent)
Grok’s JSON envelope frequently omits
usage.input_tokens/output_tokens. The previous pattern of storingNoneintoMetricsinteger fields breaks aggregation in the shared runner:This PR:
0inside_usage_metricsNone → 0in_accumulate_metricsas a defensive invariant for all providersThis is intentional fail-soft for accounting only. It does not invent business outcomes or hide failed CLI runs.
6. Localhost / proxy hygiene
The provider sets default
NO_PROXY/no_proxyfor127.0.0.1,localhost,::1so control-plane traffic is not accidentally routed through local HTTP proxies during harness sessions.7. What this PR deliberately does not do
--json-schemaconstrained decoding (can be a follow-up).agentfield_output.jsonschema strategy in the runnerAPI / config surface
SUPPORTED_PROVIDERSincludes"grok"HarnessConfig.providerdocuments"grok"HarnessConfig.grok_bin(default"grok")XAI_API_KEYExample:
Files
sdk/python/agentfield/harness/providers/grok.pysdk/python/agentfield/harness/providers/_factory.pygroksdk/python/agentfield/harness/_availability.pygroksdk/python/agentfield/harness/_runner.pysdk/python/agentfield/types.pygrok_bin+ provider docssdk/python/tests/test_harness_factory.pysdk/python/tests/test_harness_grok_provider.pyTest plan
build_provider(HarnessConfig(provider="grok"))returnsGrokProvidergrok_binis honored0(notNone)scriptcontrol-character noisegroksdk/pythonharness unit tests on this branchgrokinstalled and logged in, run a short harness task withprovider="grok"and confirm non-errorRawResultCompatibility
PATH(orgrok_bin) for live runsFollow-ups (out of scope)
--json-schemastructured decoding for Grok