Codex、Grok Build 與 OpenClaude 編碼智能體比較

Claude predates the "little crayfish" (OpenClaw), while Grok Build and Codex both came after it. As a result, Grok and Codex are closer to the OpenClaw design in how they handle queries and session management. (See the separate rough breakdown of the OpenClaw architecture.) At heart, all three are a synthesis of plan, loop, react, and spawn-agent.

What the Three Have in Common

All three are "terminal-first coding agents": they read code, edit files, run commands, call tools, connect to MCP, and manage sessions. The difference is not whether these capabilities exist, but at which layer they sit.

• Grok Build: a multi-crate actor/ACP architecture. Sampling backends converge in the Sampler. Verifying "is it really done" is handled by a multi-skeptic flow enforced by the harness. For editing, it uses hashline anchors to turn "which line I changed" into a verifiable fact.
• Codex: a submission queue plus an event stream (Op → EventMsg). Approval, sandbox selection, execution, and escalated retry after rejection are all centralized in the orchestrator. Completion is judged mainly by prompting the model to self-audit, while action safety is handled separately by Guardian.
• OpenClaude: a single-process asynchronous generator, queryLoop. Internally it uses the Anthropic message format as the standard and writes shims for other vendors. Planning has an explicit Plan Mode state machine; completion is judged by a lightweight evaluator, and the verification agent runs only when the model chooses to call it.

On the product feature list, the overlap is very high:

So when choosing, the feature tables are nearly a tie. What really separates them is: who judges completion, whether the sandbox wraps the process or each tool call, whether model adaptation lives in the sampling layer or a shim layer, and how editing prevents changing the wrong line.

Basic Comparison

Architectural Differences Among the Three

5.1 Architectural Style

Codex is "a submission queue plus an event stream." The front end only submits an Op to the session, and the session returns EventMsg. On the session side, submission_loop is the entry point, and run_turn then enters sampling. The UI, exec, app-server, and SDK are all clients of this bus. The advantages are a stable protocol, auditability, and IDE/cloud services that can reuse the same session model.

Grok Build is actors plus ACP. Sampling is split into an independent SamplerActor (raw stream, event conversion, a handle with retry and cancellation, plus doom-loop detection). The session itself is the agent side of ACP. leader/relay handles multiple clients and remote sessions. The advantage is that the TUI, editors, and headless mode can share the same agent, and backend differences do not leak into session logic.

OpenClaude is a single-process generator. query() yields messages all the way through, and the UI, tools, compaction, and permissions all hang off this loop. Changing features is fast and the call stack is intuitive, but its process boundaries and type isolation are weaker than the other two.

2. Where Model Adaptation Lives

• Codex: designed around the Responses API. Some OpenAI capabilities (remote compact, Realtime, etc.) are built into core. The chat wire API once present in config has been removed. Local models are an additional client, not an internal standard format.
• Grok Build: ApiBackend has three enum variants. Differences stop at the sampling layer, and the session consumes only unified events. This suits connecting both a first-party API and compatible protocols at the same time.
• OpenClaude: keeps Anthropic Messages as the internal standard, and other vendors get a translation layer (stripping think tags, normalizing tool parameters, cleaning schemas). It has the widest coverage and also the most patches. Internal "small calls" such as compaction and evaluation go through the same shim, so stability on non-Anthropic backends depends on translation quality.

3. Where Sandboxing and Permissions Live

• Codex: decided at tool execution time. The orchestrator's order is approval, sandbox selection, execution, and escalated retry after rejection, without asking for approval again. In addition, execpolicy and Guardian review whether the user's authorization covers the specific payload.
• Grok Build: Landlock/Seatbelt wraps the whole process at startup, and child processes then get tighter network restrictions. Within a session there are also permission-rules and sandbox profiles (Workspace / Devbox / Custom), and hooks' pre_tool_use can allow/ask/deny and rewrite inputs.
• OpenClaude: upper-layer command analysis and permission rules come first, and the sandbox runtime is an external package. It is flexible, but isolation strength depends on whether the dependencies and rules are fully written.

Figure: Layered architecture — Grok Build / Codex / OpenClaude

Grok Build Module Map

• Entry: xai-grok-pager-bin assembles the TUI; headless/CI goes through the shell.
• UI: 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: the Tool trait from xai-tool-runtime, plus xai-grok-tools (including ported implementations).
• Environment: xai-grok-workspace (filesystem, VCS, checkpoints), xai-grok-sandbox, xai-grok-mcp.
• Agent definitions: Markdown + YAML frontmatter (.grok/agents). permissionMode includes default / acceptEdits / dontAsk / plan; completionRequirement can force a particular tool call before the turn is allowed to end.

Figure: grok-build (simplified)

TUI
 ↓
ACP / leader
 ↓
Session actor
 ├─→ Sampler, 3 backends
 └─→ Tool trait + sandbox (process-level)

Figure: grok-build (crate level)

ClientSpace
  ├─ grok (binary / main CLI)
  └─ IDE or External Application
        ↓
ProtocolLayer
  Agent Client Protocol (ACP)
        ↓
  xai-acp-lib (Protocol Library)
        ↓
AgentLayer
  xai-grok-shell (Shell & Session Manager)
        ↓
  xai-grok-shell-session-support
        ↓
  xai-grok-agent (Agent Core)
        ↑ (Tool Calls & Results) → back to xai-grok-shell

Figure: grok-build (detailed module map, part 1)

[Clients]
  Editor / IDE (ACP client) | headless / CI | xai-grok-pager-bin (TUI main program)
        ↓
[ACP]
  leader / relay (multi-client and remote sessions)
  Session actor: acp_session · compaction · goal · memory
  xai-grok-agent: prompt · subagent · plugins
  permission-rules / hooks
        ↓
[Tools]                                             [Sampling (xai-grok-sampler)]
  xai-tool-runtime: Tool trait / Dispatch             SamplerActor: retry · cancel · doom-loop
  xai-grok-tools: grok_build · codex port ·           ApiBackend: ChatCompletions / Responses / Messages
                  opencode port
  xai-grok-mcp
        ↓
[Workspace]
  xai-grok-workspace: filesystem · VCS · checkpoints
  xai-grok-sandbox: nono: Landlock / Seatbelt

Figure: grok-build (detailed module map, part 2, by layer)

[Entry & Product layer]
  xai-grok-pager-bin
    ├─ Headless / stdio / ACP
    └─ xai-grok-pager: TUI / input / rendering / Modals

[Agent Runtime layer]
  xai-grok-shell
    ├─ Context assembly
    └─ Agent Loop / response parsing → tool-call dispatch

[Capability & Workspace layer]
  xai-grok-tools
    ├─ xai-grok-workspace
    ├─ MCP / Skills / Plugins / Hooks
    └─ Search / file editing / terminal

[Infrastructure layer]
  Model API / streaming responses | Config / Sandbox / shared crates | Filesystem / Git / Checkpoints

Grok Build flow: client (TUI / ACP editor / headless) → leader/relay → Session actor → permissions and hooks → SamplerActor → ApiBackend; Session → Tool runtime → tools / MCP / workspace → sandbox.

Codex Module Map

• Packaging: codex-cli is an npm launcher; the real binary is in codex-rs/cli.
• Interfaces: tui, exec (non-interactive), app-server (JSON-RPC/daemon).
• Core: core's ThreadManager/Session, protocol, state, history, rollout.
• Models: model-provider, codex-api (Responses + SSE).
• Tools: tools/router + registry; handlers include apply_patch and unified_exec; also mcp, multi-agent, and code-mode (V8).
• Security: sandboxing::SandboxManager, linux-sandbox, windows sandbox, network-proxy, execpolicy, guardian.
• Extension directory ext/: goal, memories, web-search, skills, etc. are attached to core as extensions.

Figure: codex (simplified)

TUI / exec / SDK
 ↓
app-server JSON-RPC
 ↓
Op queue + Turn
 ├─→ Responses API
 └─→ Orchestrator + sandbox (per tool call)

Figure: codex (entry points and core engine)

Entry Points
  codex binary (cli/src/main.rs)
    ├─ MCP Server (mcp-server/src/main.rs)
    ├─ App Server (IDE) (app-server/src/lib.rs)
    ├─ Non-Interactive Exec (exec/src/lib.rs)
    └─ Interactive TUI (tui/src/lib.rs)
        ↓
Core Engine (codex-core)
  ThreadManager (core/src/thread_manager.rs)
    → CodexThread (core/src/codex_thread.rs)
      → Session (internal) (core/src/session/mod.rs)
          ├─ ModelClient (core/src/client.rs)
          └─ ContextManager (core/src/context_manager.rs)
        ↓
Tool Execution
  ToolRouter (core/src/tools/mod.rs)
    ├─ Platform Sandboxes (core/src/sandboxing.rs)
    ├─ McpManager (core/src/mcp/mod.rs)
    └─ UnifiedExecProcessManager (core/src/unified_exec.rs)

Figure: codex (installation and commands)

Installation                         Commands (cli/src/main.rs)              Core Runtime (core/src/lib.rs)
  npm install -g @openai/codex  ┐      codex (TUI)                        ┐
  brew install --cask codex     ├──→   codex exec 'task' (non-interactive) │
  GitHub Releases platform      ┘      codex app-server (JSON-RPC)         ├──→ ConfigBuilder → AuthManager → ThreadManager
  binaries                             codex mcp-server (MCP stdio)        │
                                       codex review (Code Review)          │
                                       codex cloud (Cloud Tasks)           ┘

Figure: codex (detailed module map, part 1)

[Entry]
  codex-cli: npm launcher (codex.js) | codex-rs/cli: subcommand dispatch | sdk/typescript · sdk/python
  codex-tui | codex-exec: non-interactive | app-server: JSON-RPC / daemon
        ↓
[Core]
  ThreadManager / Session
  submission_loop: Op queue → EventMsg stream
  run_turn → run_sampling_request
  context_manager: compact · memories
        ↓                                            [Model layer]
[Tool layer]                                           model-provider(-info)
  tools/router + registry                              codex-api: Responses API · SSE
  tools/orchestrator: approval → sandbox selection → execution → escalated retry
  handlers: apply_patch · unified_exec · mcp · multi_agents · code-mode
  execpolicy · guardian
        ↓
[Security layer]
  sandboxing::SandboxManager
  Seatbelt · bwrap+Landlock · Windows
  network-proxy

Figure: codex (detailed module map, part 2)

[Clients & Entry]  codex-tui ⇄ codex-app-server / codex-cli
[Business core]    codex-api / codex-client / codex-core / codex-tools / Tool Orchestration / Skills / MCP / Multi-Agent
[Execution & Security]  Approval / Permission Policy → codex-sandboxing → Unified Exec / PTY / Apply Patch / Filesystem
[Communication & State] Session / Thread ⇄ Thread Store / Rollout / Protocol / Events

Codex flow: cli / tui / exec / app-server / SDK → Session submission_loop → run_turn → model-provider / Responses; within the same turn, tools router → orchestrator → handlers with sandbox / network-proxy; Guardian and execpolicy are inserted before execution.

OpenClaude Module Map

• Entry: bin/openclaude → main/cli entrypoints; build output is dist/cli.mjs.
• UI: src/ink, components, screens, commands.
• Engine: src/query.ts is very large (on the order of 100K+ bytes), accompanied by compact, stopHooks, tokenBudget, toolFailureLoopGuard, and agentStepLimit.
• Tools: src/tools/*Tool; each tool carries its own permissions and part of its UI.
• Models: 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.

Figure: openclaude (simplified)

Ink UI / SDK / gRPC
 ↓
QueryEngine
 ↓
queryLoop generator
 ├─→ Anthropic format + multi-vendor shims
 └─→ Tool + permission rules + external sandbox

Figure: openclaude (code entity space and natural-language space)

Code Entity Space
  bin/openclaude → dist/cli.mjs
     → src/entrypoints/init.ts / src/bootstrap/state.ts
     → src/screens/REPL → src/core/QueryEngine.ts → src/services/api/client.ts
        → python/smart_router.py / src/services/api/openaiShim
     → src/utils/providerProfiles.ts
Natural Language Space
  User terminal CLI → Agentic Loop & Tool Calls → LLM Provider & Shim → Provider Profiles & Config

Figure: openclaude (Query Engine and tool execution)

Natural Language Space: user's natural-language input
   ↓ parses /commands
Command Registry (src/commands): executes command logic
   ↓
QueryEngine (src/QueryEngine): prepares context (ToolUseContext)
   ↓ invokes tools based on LLM output
Tool (src/Tool.ts) → calls external APIs → LLM Provider Layer

Figure: openclaude (detailed module map, part 1)

[Entry (Bun build → dist/cli.mjs, runs on Node)]
  bin/openclaude / main.tsx · entrypoints/cli.tsx / SDK · MCP server · gRPC · VS Code extension · bridge
        ↓
[UI] React + Ink: components · screens · commands
        ↓
[Engine]
  QueryEngine
  query() / queryLoop async generator
  compact · contextCollapse · memdir · repo map
   ↙                                                   ↘
[Model access]                                        [Tools & permissions]
  services/api/client · claude.ts                       Tool.ts / buildTool
  openaiShim · codexShim                                tools/*: Bash · FileEdit · Agent · MCP · Web · LSP ...
  Gemini · Vertex · Bedrock                             utils/permissions: bash classifier · rules
  integrations/: vendors · gateways · registry          sandbox-adapter: @anthropic-ai/sandbox-runtime

Figure: openclaude (detailed module map, part 2)

[Model adaptation layer]  Provider / Model config → Anthropic-compatible / OpenAI-compatible / Ollama (local models) / Other providers
[Interaction & product entry]  VS Code Extension / Headless gRPC / Slash Commands / CLI / REPL
[Agent Runtime]  Conversation / message management → Context Repo Map → Model response & tool-call loop → Agent Routing / Tasks
[Tools & extensions]  Tool Registry / Explore / Plan / Subagents / Skills / Hooks / Plugins / Files / Grep / Glob / Bash / MCP / Web tools

OpenClaude flow: bin/CLI or SDK/gRPC/VS Code → Ink UI → QueryEngine.queryLoop → tools and permissions → sandbox adapter; a parallel branch goes into the services/api shims → each provider. Compaction, goal evaluation, and stop hooks all hang between yields of the same loop.

Notes on Provenance and History

• Grok Build's THIRD-PARTY-NOTICES show that apply_patch, grep_files, list_dir, read_file, etc. are ported from openai/codex, while bash, edit, glob, grep, read, skill, todowrite, write, etc. come from sst/opencode. So "four sets of editing tools coexisting" is historical layering, not accidental duplication.
• xai-grok-shell contains claude_import and external-agent-migration, providing migration from Claude-family configuration.
• OpenClaude's QueryEngine, Tool.buildTool, BashTool, and AgentTool naming matches the Claude Code structure, with multi-provider support added on top. Some tool files (such as VerifyPlanExecution, REPL, and SuggestBackgroundPR in early notes) were once nearly empty shells. When integrating, go by the actual current line counts of the files, and don't assume every tool name has a complete implementation.

Design Differences Among the Three

Planning, Completion Judgment, and Action Risk

Grok's verification design deliberately guards against "feeling good about itself": if the planner fails, the goal is paused (fail-closed); if the strategist or summarizer fails, it does not block (fail-open). The strategist writes only strategy notes, and a guard snapshot is used to restore plan.md on entry and exit, so it cannot rewrite the contract the verifiers have already judged. The diff the skeptics see is placed in a restricted directory rather than being stuffed into the prompt without limit.

Codex writes "don't swap the goal" into its continuation template: you may not switch to a smaller plan just because tests pass more easily; every requirement needs evidence of its current state, and insufficient evidence counts as incomplete. The cost is that by default there is no second model to overturn this conclusion. Guardian governs whether an action is authorized, not whether the code is correct.

OpenClaude's verification agent prompt is strict: don't modify the project, must paste the actual commands and output, must run adversarial probes before PASS, and must end with a VERDICT. But whether to call it is decided by the model, not enforced by the harness every round. Plan Mode also has 5 phases (understand → design → review → write plan file → ExitPlanMode) and an Interview variant: if the code can answer it, don't ask the user, and plan approval can only go through the Exit tool.

Figure: Who decides a coding task is finished?

Editing, Code Understanding, Compaction, and Failure Recovery

The three editing philosophies can be summed up like this: Codex lets patches tolerate small differences; OpenClaude requires proving, before editing, that the file hasn't been changed by someone else; Grok tries to use anchors to prove "the line I'm changing is exactly the one I read at the time." Hashline sits next to a benchmark, and the multiple anchor schemes are still experimental routes. Their coexistence with the ported apply_patch suggests the choice is made per model and scenario, rather than leaving only one winner.

On depth of code understanding, Grok is the most complete: an offline symbol graph plus online LSP plus distinguishing agent edits from user edits has direct value when "a person and an agent edit the same repo at the same time." On compaction, OpenClaude has the most layers, Grok has the strictest summary contract, and Codex is the lightest, allowing the model to decide when to start fresh context and to keep state in files and tasks.

How Decision-Making and Coding Mesh

• Planning without writing code: all three can do it, but OpenClaude and Grok intercept write tools at runtime, while Codex relies more on the plan template to keep the model from emitting write actions.
• Wrote it but the numbers don't add up: Grok has independent readers challenge the diff; Codex has the same model look for evidence against the requirements; OpenClaude uses cheap evaluation calls, with deep verification as an optional agent.
• How to back out after a wrong write: Grok has workspace checkpoints and hunk attribution; Codex relies on patch match failures and turn diffs; OpenClaude relies on read timestamps and pre-write backups.
• Parallelism: Grok's subagent/worktree and goal panel are first-class flows; Codex has multi-agent and cloud tasks, but sessions default to a single-line turn; OpenClaude explicitly allows parallel Explore/Plan agents in the Plan Phase, with a step cap.

External Reviews and Community Voices, and How to Use Them

Selection Guidance

• If you need to see whether approval, sandboxing, and execution policy are auditable: read Codex's orchestrator, SandboxManager, Guardian, and app-server first.
• If you need multi-backend sampling, editor ACP, and "don't declare completion early": read Grok's sampler, ACP, goal/skeptic, hashline, and workspace checkpoint first.
• If you want to modify the harness across many vendor APIs and count costs in TypeScript: read OpenClaude's queryLoop, planMode, and integrations first. Accept the shim debt, and confirm one by one that tools are not placeholders.
• Don't substitute licenses or star counts for a security review: although Grok and Codex are open source, they don't accept external patches, and the pace of issue fixes is set by the vendor; OpenClaude can be changed by the community, but its supply chain (sandbox package, provider gateways) is more scattered.

Overall Take

Overall, openclaude ships with more tool detail out of the box, while for codex and grok build it is still advisable to configure more skills to improve coding ability. However, codex fits OpenAI's conservative style and has better security-boundary management, whereas grok build's architecture is clearer and more flexible.