Codex / Claude / Grok Agent Comparison

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.

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.

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.

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.

TUI
 ↓
ACP / leader
 ↓
Session actor
 ├─→ Sampler, 3 backends
 └─→ Tool trait + sandbox (process-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
[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
[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.

TUI / exec / SDK
 ↓
app-server JSON-RPC
 ↓
Op queue + Turn
 ├─→ Responses API
 └─→ Orchestrator + sandbox (per tool call)
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)
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)           ┘
[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
[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.

Ink UI / SDK / gRPC
 ↓
QueryEngine
 ↓
queryLoop generator
 ├─→ Anthropic format + multi-vendor shims
 └─→ Tool + permission rules + external sandbox
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
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
[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
[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.

Grok's verification design deliberately guards against "feeling good about itself": if the planner fails, the goal is d (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.

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.

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.