Codex vs Grok Build vs OpenClaude: Architectural Showdown of AI Coding Agents

All three agents are “terminal-first coding agents” that read code, edit files, run commands, call tools, connect to MCP, and manage sessions. Their functional overlap is high; the real differences lie in which layer each capability lives in.

Architectural Styles

Codex uses a “submission queue + event stream” (Op → EventMsg). The front-end only pushes Ops into the session; the session returns EventMsg. The session-side submission_loop is the entry point, which then calls run_turn to enter sampling. UI, exec, app-server, and SDK are all clients of this single bus, giving stable protocols, auditability, and reuse across IDE and cloud tasks.

Grok Build adopts an actor + ACP (Agent Communication Protocol) design. Sampling is split into an independent SamplerActor (raw stream, event transformation, retry/cancel handling, and doom-loop detection). The session itself is an ACP agent endpoint. A leader/relay handles multi-client and remote sessions. This lets TUI, editor, and headless modes share the same agent while keeping backend differences out of session logic.

OpenClaude is a single-process async generator: queryLoop yields messages all the way down. UI, tools, compaction, and permissions all hang on this loop. It uses Anthropic Messages as the internal standard and writes shims for other vendors. It has an explicit Plan Mode state machine; completion judgment is a lightweight evaluator, and verification relies on the model proactively calling a verification agent. The upside is fast iteration and a clear call stack, but process boundaries and type isolation are weaker than the other two.

Where Model Adaptation Lives

Codex: Built around OpenAI’s Responses API. Some OpenAI capabilities (remote compact, Realtime) are baked into core. The old chat wire API config has been removed. Local models are attached as external clients, not as the internal standard format.

Grok Build: Uses an ApiBackend enum with three variants. Differences stop at the sampling layer; the session only consumes unified events. This suits simultaneously serving a proprietary API and compatible protocols.

OpenClaude: Keeps Anthropic Messages as the internal standard; other vendors get a translation layer (think-tag cleaning, tool-parameter normalization, schema cleaning). Coverage is widest, but patch count is highest; internal “small calls” like compaction and evaluation also go through the shim, so non-Anthropic backend stability depends on translation quality.

Sandbox and Permission Placement

Codex: Decides at tool-execution time. The orchestrator sequences approval → sandbox selection → execution → on rejection, upgrade retry without re-approval. Separate execpolicy and Guardian review whether the concrete payload is covered by user authorization.

Grok Build: Wraps the whole process in Landlock/Seatbelt at startup, then further tightens network for child processes. Inside the session there are permission-rules and sandbox profiles (Workspace / Devbox / Custom). Hooks’ pre_tool_use can allow/ask/deny and rewrite inputs.

OpenClaude: Relies mainly on high-level command analysis and permission rules; the sandbox runtime is an external package. Flexible, but isolation strength depends on whether dependencies and rules are exhaustive.

Module Maps (Key Crates/Packages)

Grok Build: Entry via xai-grok-pager-bin (TUI) or shell (headless/CI). UI in xai-grok-pager, render, diff, status-line. Runtime: xai-grok-shell (session, compaction, goal, memory) and xai-grok-agent (definition parsing, prompt assembly, subagent, plugins). Sampling: xai-grok-sampler. Tools: xai-tool-runtime ’s Tool trait plus xai-grok-tools (ported implementations). Environment: xai-grok-workspace (FS, VCS, checkpoints), xai-grok-sandbox, xai-grok-mcp. Agent definitions are Markdown + YAML frontmatter in .grok/agents with permissionMode (default/acceptEdits/dontAsk/plan) and completionRequirement that can force a specific tool call before ending a turn.

Codex: Wrapper: codex-cli npm launcher; real binary in codex-rs/cli. Interfaces: tui, exec (non-interactive), app-server (JSON-RPC/daemon). Core: core ’s ThreadManager/Session, protocol, state, history, rollout. Model: model-provider, codex-api (Responses + SSE). Tools: tools/router + registry; handlers include apply_patch, unified_exec; also mcp, multi-agent, code-mode (V8). Safety: sandboxing::SandboxManager, linux-sandbox, windows sandbox, network-proxy, execpolicy, guardian. Extensions in ext/ (goal, memories, web-search, skills) plug into core.

OpenClaude: Entry: bin/openclaude → main/cli entrypoints, build artifact dist/cli.mjs. UI: src/ink, components, screens, commands. Engine: src/query.ts (large, ~100KB), with compact, stopHooks, tokenBudget, toolFailureLoopGuard, agentStepLimit. Tools: src/tools/*Tool, each with own permissions and partial UI. Model: src/services/api and src/integrations (vendors, gateways, registry). Permissions: src/utils/permissions including a bash classifier. Periphery: memdir, repo map, grpc, daemon/background sessions, vscode-extension.

Shared Tool Heritage

Grok Build’s THIRD-PARTY-NOTICES shows apply_patch, grep_files, list_dir, read_file ported from openai/codex; bash, edit, glob, grep, read, skill, todowrite, write from sst/opencode. Hence “four editing tool families coexist” is historical layering, not accidental duplication. xai-grok-shell also contains claude_import and external-agent-migration for migrating from Claude-style configs. OpenClaude’s QueryEngine, Tool.buildTool, BashTool, AgentTool naming and structure mirror Claude Code, with multi-provider added on top. Some tool files (e.g., early VerifyPlanExecution, REPL, SuggestBackgroundPR) were near-empty stubs; integration must check current line counts, not assume every named tool is fully implemented.

Verification Design Philosophies

Grok deliberately prevents “self-satisfaction”: planner failure pauses the goal (fail-closed); strategist and summarizer failures don’t block (fail-open). Strategist only writes strategy notes; on entry/exit it snapshots and restores plan.md under a guard to avoid overwriting the verifier’s settled contract. The skeptic reviews a diff placed in a restricted directory, not an unbounded prompt injection.

Codex encodes “don’t swap the goal” into the continuation template: must not replace the solution with a smaller one just because tests pass easier; every requirement needs current-state evidence, lack of evidence means incomplete. Cost: no second model to challenge that conclusion by default. Guardian governs action authorization, not code correctness.

OpenClaude ’s verification agent prompt is strict: no project edits, must paste actual commands and outputs, adversarial probing required before PASS, ends with VERDICT. But it’s model-decided whether to call it, not a harness-enforced every-turn step. Plan Mode has five phases (Understand → Design → Review → Write plan file → ExitPlanMode) and an Interview variant: if code can be read, don’t ask the user; plan approval only via the Exit tool.

Editing Philosophies

Codex makes patches tolerate small diffs.

OpenClaude demands proof the file hasn’t been changed by others before editing.

Grok tries to prove “I edited exactly the line I read” via hashline anchors. hashline has benchmarks; multiple anchor strategies coexist with the ported apply_patch, indicating selection per model and scenario rather than a single winner.

Code Understanding Depth

Grok is most complete: offline symbol graph + online LSP + distinction between agent and user edits, directly valuable for “human and agent editing the same repo simultaneously.” On compaction, OpenClaude has the most layers, Grok’s summary contract is strictest, Codex is lightest and lets the model decide when to start a new context, leaving state in files and tasks.

Decision–Coding Interlock

Plan-only, no code: All three support it. OpenClaude and Grok intercept write tools at runtime; Codex relies more on plan-template constraints to stop the model from emitting write actions.

When is writing “done”?: Grok uses an independent reader to challenge the diff; Codex uses the same model to find evidence against requirements; OpenClaude uses a cheap evaluation call, with deep verification as an optional sub-agent.

Rollback on mistakes: Grok has workspace checkpoints and hunk attribution; Codex relies on patch-match failure and turn diff; OpenClaude uses read timestamps and pre-write backups.

Parallelism: Grok’s subagent/worktree and goal panels are first-class flows; Codex has multi-agent and cloud tasks but default session leans single-turn; OpenClaude explicitly allows parallel Explore/Plan agents in Plan Phase with step limits.

Source-Code Reading Guide

For auditable approval, sandbox, execution strategy: read Codex’s orchestrator, SandboxManager, Guardian, app-server.

For multi-backend sampling, editor ACP, and “don’t declare done early”: read Grok’s sampler, ACP, goal/skeptic, hashline, workspace checkpoint.

For hacking harnesses across many provider APIs with TypeScript cost accounting: read OpenClaude’s queryLoop, planMode, integrations. Accept shim debt and verify each tool isn’t a placeholder.

Don’t substitute license or star count for security review. Grok and Codex are open-source but don’t accept external patches; fix cadence is vendor-driven. OpenClaude is community-modifiable, but its supply chain (sandbox packages, provider gateways) is more fragmented.

Overall, OpenClaude ships more built-in tool detail, while Codex and Grok Build benefit from configuring additional skills to sharpen coding ability. Codex matches OpenAI’s conservative style with stronger safety boundaries; Grok Build’s architecture is cleaner and more flexible.