The easy comparison between OpenAI Codex and Grok Build is a feature checklist. Both are terminal coding agents. Both edit files, execute commands, call MCP servers, spawn subagents, compact context, resume sessions, use worktrees, and run headlessly.

That comparison is accurate and almost completely useless.

After building both projects, running both against the same local model, and reading the machinery behind their advertised features, I think they are aiming at different products.

Codex is becoming an agent operating system. Grok Build is becoming an unusually accountable IDE.

Codex has the deeper execution platform: a JavaScript tool-orchestration VM, an offline causal trace reducer, cross-platform command sandboxes, a policy-enforcing network proxy, a remote execution plane, a large rich-client protocol, realtime voice, and a cloud task inbox.

Grok Build has the better machinery around the act of changing code: a persistent Tree-sitter symbol graph, durable hunk identity and authorship, coherent conversation-and-filesystem rewind, line-commentable plan review, excellent background task UX, standard ACP integration, and broad compatibility with the Claude and Cursor ecosystems.

If I were building an agent platform, I would steal more from Codex. If I were building the coding agent I wanted beside me all day, I would steal more from Grok.

The short version

These findings refer to two exact public snapshots:

• Codex commit 800715d20, 16 July 2026.
• Grok Build commit b189869, published 15 July 2026.

That qualification matters. Grok Build says its repository is periodically synced from SpaceXAI’s monorepo. A feature missing from the public tree is not proof that no internal implementation exists. I am comparing source, not corporate telepathy.

Building both

Both projects are large Rust workspaces. Neither is a weekend CLI wrapped around an API call.

Grok Build

I cloned Grok Build and checked out b189869. The repository’s build instructions say to build the xai-grok-pager-bin package:

git clone https://github.com/xai-org/grok-build.git
cd grok-build
cargo build -p xai-grok-pager-bin --release

My first build failed in protobuf generation:

bin/protoc found at `../../../bin/protoc` but failed to execute:
env: ‘dotslash’: No such file or directory
`protoc` not found

The checked-in bin/protoc is a DotSlash launcher. Installing the documented dependency fixed it:

cargo install dotslash --locked
export PATH="$HOME/.cargo/bin:$PATH"
cargo build -p xai-grok-pager-bin --release

The successful release build took 4 minutes 33 seconds on my machine. The resulting binary was 201 MB:

grok 0.1.220-alpha.4 (b189869)
target/release/xai-grok-pager  201M

There were four future-compatibility warnings in the web-search client about unsuffixed f32 literals, but no source patch was required. The repository remained clean.

Codex

Codex’s canonical instructions live in docs/install.md. Its Rust workspace is under codex-rs:

git clone https://github.com/openai/codex.git
cd codex/codex-rs
cargo build

The full documented debug build completed without modification. The only notable warnings came from vendored Bubblewrap C code partially initializing sockaddr_nl.

The resulting debug binary was an absurd 1.7 GB:

codex-cli 0.0.0
target/debug/codex  1.7G

That number is not a fair release-size comparison: one binary is optimized, the other is a full debug build containing a small civilisation’s worth of symbols. It does convey the scale of the workspace. Codex currently has crates for the app server, exec server, network proxy, Linux and Windows sandboxes, Code Mode, rollout tracing, memories, plugins, hooks, cloud tasks, realtime WebRTC, connectors, state projections, and more. cargo build has opinions about your SSD.

Running both locally

I wanted to separate harness behaviour from hosted-model behaviour, so I pointed both builds at the same local Ollama model, qwen3.6:27b.

Codex has a direct local-provider path:

codex exec \
  --oss \
  --local-provider ollama \
  --model qwen3.6:27b \
  --sandbox read-only \
  "Reply with exactly: Codex local build works."

It completed successfully:

provider: ollama
sandbox: read-only
Codex local build works.

Grok supports custom OpenAI-compatible endpoints through config.toml:

[models]
default = "ollama-qwen"

[model.ollama-qwen]
model = "qwen3.6:27b"
base_url = "http://127.0.0.1:11434/v1"
name = "Qwen 3.6 27B (local Ollama)"
api_backend = "chat_completions"
context_window = 131072

A quirk: even a custom local model still passed through Grok’s authentication check. Supplying a dummy XAI_API_KEY allowed the custom endpoint to run; no request went to xAI because the selected model’s base URL was local.

XAI_API_KEY=local GROK_HOME=/tmp/grok-local \
  grok -p "Reply with exactly: Grok local build works." \
  -m ollama-qwen

It also completed successfully:

Grok local build works.

I then captured both TUIs in a real 120×36 pseudo-terminal. These are rendered from the actual ANSI terminal buffers, not reconstructed marketing mockups.

The answers in the screenshots are wrong in opposite directions. Codex’s local model calls Grok Build browser-hosted; Grok’s local model confuses the current Codex agent with the old GPT-3-era Codex model. This is useful evidence, not an embarrassment to hide: the harness can provide an excellent environment, but a model cannot compare two repositories it has never seen. The rest of this article comes from their source, not those answers.

Codex: tools become a programming language

The most unusual mechanism in either repository is Codex Code Mode.

Normally an agent calls a tool, receives output into its context, reasons again, then calls another tool. This is flexible but expensive. Every intermediate result becomes model-visible text, and every branch requires another inference step.

Code Mode allows the model to emit JavaScript that composes the existing tool universe. The model-facing contract describes raw JavaScript evaluated as an async module in a fresh V8 isolate. Tools appear as generated globals derived from their schemas.

Conceptually:

const [tests, diff, status] = await Promise.all([
  tools.exec_command({ cmd: "cargo test" }),
  tools.exec_command({ cmd: "git diff --stat" }),
  tools.exec_command({ cmd: "git status --short" }),
]);

if (tests.exit_code !== 0) {
  return {
    status: "failed",
    failures: extractFailures(tests.output),
    diff,
  };
}

return { status: "passed", diff, worktree: status.output };

This is not Node.js and not an escape hatch around policy:

• no direct filesystem;
• no direct network;
• no console;
• each cell receives a fresh isolate;
• only explicitly serializable values survive through store() and load();
• nested tools still go through Codex approvals, cancellation, sandboxing, and tracing.

The runtime also supports yield_control(), waiting on a still-running cell, and notifying an active model turn. The Session abstraction can run in-process or through a remote host. Codex even checks whether the selected model advertises support and warns about forcing Code Mode onto an unsuitable model.

Grok has typed tool dispatch, parallel subagents, background commands, and a headless --best-of-n mode. It has no equivalent embedded orchestration VM.

Code Mode could reduce inference turns and keep noisy intermediate data away from the model. It also creates a fresh category of failure: the model can now write orchestration bugs, leak resources in abandoned cells, mishandle schemas, or create a concurrent mess that is harder to understand than sequential tool calls.

Codex’s answer to that second problem is nearly as interesting as Code Mode itself.

Codex: observe first, interpret later

codex-rollout-trace records a local diagnostic bundle and reduces it offline into a semantic graph.

The hot path does not try to maintain one perfect live graph. It appends ordered observations and writes large payloads separately:

manifest.json
trace.jsonl
payloads/*.json
state.json

A deterministic reducer later reconstructs:

• threads and turns;
• model-visible conversation items;
• inference requests;
• direct tool calls;
• nested Code Mode calls;
• terminal sessions and operations;
• compaction checkpoints;
• parent/child agent interactions;
• information-flow edges;
• references back to raw evidence.

The essential distinction appears explicitly in the design: runtime payloads are evidence, not proof that the model saw the same bytes.

A JavaScript cell may receive a nested tool result that never appears verbatim in the model transcript. A child agent may produce a runtime event before its result is delivered to the parent. A terminal operation may reuse a process created several turns earlier. A normal transcript collapses these distinctions. Codex preserves them.

Tracing is opt-in through CODEX_ROLLOUT_TRACE_ROOT, local-only, best effort, and highly sensitive. It can contain prompts, terminal output, paths, and tool payloads. It is diagnostic evidence, not telemetry, and trace failure must never fail the coding session.

Grok has persisted sessions, streaming capture, debug logging, and trace export/upload commands. It does not have this source-visible offline causal reducer. Codex is solving the debugging problem created by its own more programmable and distributed runtime—which is exactly when sophisticated tracing stops being ornamental.

Codex: a security system, not just an approval dialog

Both projects implement real OS sandboxing. The differences are in granularity and network control.

Filesystem and process isolation

Grok applies an irreversible profile to the entire process at startup. Its sandbox guide documents Landlock/Bubblewrap on Linux and Seatbelt on macOS. In-process file tools and children inherit the same filesystem restrictions. Custom deny globs can block reads as well as writes and renames. A session’s profile is retained across resume.

Codex constructs sandbox policy around individual executions. Its sandboxing, linux-sandbox, and windows-sandbox-rs crates cover Bubblewrap, seccomp, macOS Seatbelt, Windows restricted tokens, ACLs, private desktops, and ConPTY. Commands can request additional permissions rather than widening the complete session.

Codex also performs pre-main process hardening: disabling core dumps, making Linux processes non-dumpable, removing loader-injection environment variables, and denying debugger attachment on macOS.

Grok’s process-wide model is simpler to reason about. Codex’s command-scoped model is more flexible, supports Windows substantially better, and enables meaningful privilege escalation for one operation.

Mediated network access

Codex then goes much further with codex-network-proxy.

It provides HTTP and SOCKS5 proxies with:

• domain allow and deny lists;
• private and loopback address protection;
• a limited mode allowing only GET, HEAD, and OPTIONS;
• HTTPS interception when method enforcement requires it;
• command-aware policy decisions;
• selected Unix-socket access;
• structured audit events;
• header rewrite actions;
• credential virtualization.

The credential broker can place a virtual marker in a child environment and inject the real credential only when the request reaches an approved host. The sandboxed process does not need a reusable GitHub or OpenAI token in its environment.

That is a better answer to agent networking than either unrestricted curl or no network at all. It is also expensive machinery: HTTPS MITM introduces certificate compatibility problems, pinned clients can fail, and DNS rebinding remains difficult without lower-layer enforcement.

Grok can block child networking through seccomp, consume signed enterprise policy, and honor conventional proxies. It does not have Codex’s integrated policy gateway and credential broker.

Codex: the CLI is only one client

codex app-server is a broad control-plane API used to power rich interfaces such as the Codex VS Code extension.

Its public object model is clean:

Thread
  └── Turn
        └── Item

An item may be a message, reasoning, command, file edit, approval, review transition, or tool operation. The server supports start, resume, fork, archive, search, pagination, steering, interruption, background terminals, file operations, plugins, configuration, review, realtime voice, and remote environments.

It runs over stdio JSONL, WebSocket, or WebSocket over a Unix socket. Clients can generate TypeScript definitions and JSON Schema from the exact binary version. Bounded queues reject overload rather than allowing unbounded ingress.

Grok has a genuinely substantial rich-client boundary too. Its TUI is an ACP client, and the shell exposes an ACP server with x.ai/* extensions for files, Git, worktrees, terminals, rewind, and sessions. A leader process adds persistent multi-client coordination and replay.

The trade-off is straightforward:

• Codex’s proprietary protocol is broader and maps deeply onto its native product.
• Grok’s ACP implementation is more interoperable with editors such as Zed, Neovim, and Emacs.

Codex wins breadth. Grok wins standardisation.

Codex also has a separate exec-server for remote filesystem and process authority. It provides stable process IDs, PTYs, writable stdin, sequence-numbered output, reconnect recovery, remote path URIs, and sandbox/network intent. Its remote relay uses encrypted multiplexed sessions with acknowledgement and retransmission machinery.

Grok can delegate terminal operations through ACP and includes a capable PTY controller. It lacks Codex’s complete remote execution plane and durable reconnection contract.

Grok: the repository is a data structure

Codex has excellent file search and can reason over a repository using tools. Grok goes further by maintaining a persistent parser-backed repository model.

xai-codebase-graph indexes definitions, references, imports, lexical scopes, aliases, files, and source locations for Rust, Go, Python, JavaScript, and TypeScript.

The implementation has two useful representations:

1. A detailed per-file lexical scope graph.
2. A compact repository-wide occurrence index optimised for interactive navigation.

The bulk builder parses files in bounded parallel batches, then merges them through one global string interner. Per-file reverse indexes make removal and reindexing proportional to the symbols in the changed file. Cached indexes become available quickly and are validated asynchronously. File watcher floods are coalesced before updates.

The navigation layer can locate the syntax object at a source position and query definitions or references.

This is not compiler-grade semantic resolution. Cross-file joins are largely name- and alias-based, without each language’s complete type system. The interesting part is the latency and memory architecture, not a claim that Grok secretly contains five compilers.

Codex uses Tree-sitter for narrower parsing jobs but has no comparable persistent repository-wide symbol graph in this snapshot.

For a coding agent, this matters. Repeatedly running rg, reopening the same definitions, and reconstructing repository structure in model context is reliable but wasteful. Grok has a reusable structural retrieval layer beneath that process.

Grok: a diff is not disposable text

xai-hunk-tracker treats a changed hunk as a durable object rather than something regenerated anonymously whenever the UI opens a diff.

Each hunk can retain:

• a stable UUID;
• the prompt that created it;
• whether it came from the agent or an external edit;
• whether an external edit later touched an agent-created region;
• identity across line movement;
• identity through compatible content changes;
• accept/reject state;
• rewind snapshots.

The provenance type explicitly distinguishes AgentEdit { prompt_index }, ExternalEditOnAgentFile, and External. During reconciliation, the tracker preserves hunk IDs where possible, prevents one old ID from being assigned to several split hunks, and emits semantic transitions for movement and content changes.

Accepting a hunk updates the tracker’s baseline. Rejecting a hunk patches the working file. This is richer than hiding an item in a diff view.

Codex has structured patch approval and file-change items, but decisions apply to a patch-level object. There is no persistent per-hunk identity, rematching, authorship, or selective post-edit accept/reject equivalent.

This feature is not visually spectacular. It may be the most important daily-use difference between the two agents. Once a human and an agent both touch the same file over several turns, “the agent changed this file” is no longer enough information.

Grok: rewind the work, not just the chat

Grok records a rewind point at each user prompt. Rewinding coordinates several domains:

1. Git soft restoration and safety checks.
2. Filesystem restoration.
3. Staging restoration.
4. Hunk-state reconstruction.
5. Conversation truncation.

The user-facing operation is simple: /rewind, or double Escape while idle, choose a prior prompt, and return to that state. The session format stores file snapshots for rewind.

Codex has conversation rollback and a good nondestructive backtracking workflow: choose an old prompt, fork before it, and edit the prompt on the new branch. But the Codex protocol explicitly states that rollback does not revert local file changes.

These are complementary operations:

• Fork from here preserves the failed path and explores an alternative.
• Rewind to here says the failed path should stop existing in this workspace.

Codex currently does the first better. Grok is the only one of the pair that coherently does the second.

Grok: plans are reviewable artefacts

Both products expose Plan mode. Codex has structured plan items, streaming updates, collaboration-mode settings, and an implementation prompt.

Grok turns the plan into a persisted plan.md and opens a dedicated review surface. The user can:

• select a line or range;
• attach an inline comment;
• approve;
• approve with comments;
• request changes;
• abandon the plan.

The implementation lives in plan_approval_view.rs. Comments become feedback with quoted plan snippets or line references.

Grok also gates ordinary edit tools while Plan mode is active, allowing only the plan file. The guard is imperfect: shell redirection can write, and a child subagent does not automatically inherit the parent’s plan gate. The documentation says so, which is better than pretending prompt policy is kernel policy.

Codex’s Plan mode does not offer line-level comments and does not hard-remove shell or patch capabilities. Grok’s plan is closer to a small code review than a mode-specific prompt.

Tasks, best-of-N, and the terminal as an IDE

Grok’s command lifecycle is unusually coherent. A foreground command that turns out to be long-running can be detached with Ctrl+G. Commands and subagents share output, wait, and kill tools. A tasks pane combines:

• background commands;
• subagents;
• monitors;
• recurring loops;
• completion status;
• task IDs.

The /loop and monitor documentation distinguishes periodic prompts from line-oriented event streams. A monitor can turn selected log lines into conversation notifications without dumping a complete log into context.

Codex has a stronger underlying remote execution model and can retain long-running processes, poll output, write stdin, list processes, and stop them. Grok has the better integrated terminal UX.

Both now have best-of-N stories, but they are different:

• Grok’s CLI exposes --best-of-n N in headless mode. It prefixes the task with a bundled orchestration skill and asks subagents to produce and judge candidates.
• Codex’s cloud-task client models sibling attempts, alternate messages and diffs, patch preflight, conflicts, and local application through a hosted backend.

Codex’s version is a productised cloud workflow. Grok’s is a local harness capability. My earlier source-only pass missed Grok’s CLI flag because the deeper worktree comparison path is still described as future machinery; running grok --help corrected the record. Building things is useful that way.

Extensions: architecture versus compatibility

Codex has the cleaner extension architecture.

Its extension-api defines typed contributors for thread and turn lifecycle, configuration, context, MCP, tools, items, and approval review. Native hooks cover pre/post tool use, permission requests, compaction, session start, prompts, subagents, and stop. Plugin manifests can package skills, MCP servers, apps, hooks, and user-interface metadata.

This is an in-process Rust composition API, not a stable cross-language binary ABI. Still, its internal shape is excellent: extensions contribute to named lifecycle points rather than each subsystem discovering a new way to prepend strings and register callbacks.

Grok has the better compatibility story. Its compatibility machinery discovers or imports Claude and Cursor rules, skills, permissions, MCP servers, hooks, plugins, and settings across project and user scopes. The source defines vendor compatibility controls, project rule discovery, and cross-vendor skill precedence.

Compatibility is not perfect emulation. Cursor session scanning is stubbed in this snapshot, and not every vendor hook maps exactly. But Grok makes a serious attempt to enter an existing agent-configured repository without demanding immediate conversion.

Codex instead has a substantial migration system that imports Claude and Cursor configuration, hooks, sessions, and memory into Codex’s durable model. Grok is better at coexistence; Codex is better at immigration.

Memory: both are serious, Codex is more formal

Grok’s experimental cross-session memory uses an AutoDream process to consolidate session logs into durable Markdown. It tracks processed session stems and uses a PID/mtime stale-lock protocol to avoid concurrent consolidation. The sequence is effectively acquire, consolidate, validate, write, then remove processed inputs.

Codex has a more formal two-stage pipeline, documented in codex-rs/memories/README.md.

Phase one leases eligible idle rollouts from SQLite and extracts structured raw memories and summaries in bounded parallel jobs. Phase two takes a global lease, materialises selected inputs into a dedicated Git-backed memory workspace, computes a diff against the previous baseline, and launches a tightly sandboxed consolidation agent with no network and no recursive collaboration.

At read time, Codex injects a bounded summary and exposes detailed search/read tools. Responses can include structured citations to exact memory files, line ranges, and contributing rollouts.

Grok’s pipeline is simpler and inspectable. Codex’s has stronger concurrency control, selection accounting, provenance, and failure semantics. Both remain model-generated memory: leases and citations improve accountability, not truth.

One delightful Grok flourish: offline Mermaid

Grok recognizes Mermaid fences, renders terminal-friendly Unicode art, and can generate a high-resolution PNG offline through a vendored Rust implementation and resvg.

The xai-grok-mermaid pipeline has no browser, Node runtime, network resolver, or file resolver. Rendering is lazy and off the draw thread. Because release builds use abort-on-panic semantics, Grok re-executes itself as a hidden renderer process, imposes a three-second timeout, and falls back to source rather than risking the TUI.

This is excellent engineering devoted to a secondary feature. The PNG is opened externally rather than displayed inline, and the vendored parser will inevitably lag Mermaid.js at the edges. Still: Codex uses Mermaid in its own documentation and cannot render it in the product. Grok can.

What is not a differentiator

A surprising amount of coding-agent discourse consists of awarding novelty points for table stakes.

Neither project gets a special medal here for:

• shell and file tools;
• MCP;
• skills;
• subagents;
• persistent sessions;
• context compaction;
• mid-turn steering;
• background processes;
• Git worktrees;
• local and custom models;
• headless operation;
• inline diffs;
• project instruction files;
• hooks and plugins as broad categories.

The implementations matter, but the category does not distinguish them.

What each should steal

Codex should steal from Grok

1. Durable hunk identity. Codex’s patch approval is not enough once human and agent edits overlap over several turns.
2. Coherent workspace rewind. Branching history is excellent; restoring files and transcript together is still necessary.
3. The codebase graph. Codex has strong search, but structural retrieval should not require rediscovery every turn.
4. Line-commentable plan review. Plans deserve the same feedback precision as diffs.
5. The task pane and detach workflow. Codex’s execution layer is stronger than its terminal ergonomics.
6. ACP support. A rich proprietary app protocol and a standard editor protocol can coexist.

Grok should steal from Codex

1. The rollout trace reducer. Grok already has many asynchronous actors; causal debugging will only become more valuable.
2. Network credential brokering. Sandboxed agents need scoped capability, not raw secrets.
3. Command-scoped sandbox escalation. Process-wide profiles are clear but sometimes too blunt.
4. Remote execution recovery. ACP terminal delegation is not the same as resumable execution authority.
5. Typed context fragments. Grok has typed state, but context assembly still lacks Codex’s unified diffable fragment model.
6. Memory citations. Persistent claims should point back to the sessions that produced them.

The actual split

Codex’s architecture separates several things that simpler agents collapse into a transcript:

• durable product history;
• live session state;
• model-visible context;
• runtime tool activity;
• causal diagnostic traces;
• agent topology;
• remote process state;
• consolidated memory.

That separation is why it increasingly resembles an operating system for agents. Code Mode is the programmable execution layer; app-server is the client protocol; exec-server is the process plane; the sandbox and network proxy are the security boundary; rollout tracing is the debugger.

Grok’s architecture concentrates on controlling change:

• know the repository structurally;
• preserve the identity and origin of edits;
• review the plan before execution;
• watch tasks without blocking interaction;
• integrate with existing editor and agent ecosystems;
• return the complete workspace to an earlier point when the agent goes wrong.

That makes it feel less like a platform and more like an IDE designed around an autonomous collaborator.

Codex is more technically innovative overall. Grok Build has the better ideas for making an agent trustworthy during ordinary coding.

Codex solves harder infrastructure problems. Grok answers the question I ask more often after giving an agent a real repository:

What exactly did you change, which parts are still mine, and how do I get back to before you became stupid?

For daily use, that question has an inconvenient habit of winning.