Inside the Agent Loop: How Claude Code and OpenAI Codex Actually Work

How AI Coding Assistants Actually Work

When you ask Claude Code or OpenAI's Codex to fix a bug, what happens under the hood is far more complex than a simple question-and-answer exchange. According to Anthropic's official Claude Code documentation and OpenAI's publicly available Codex source code, both tools are fundamentally a language model wrapped in an execution harness: the model proposes actions, the harness executes them, feeds the results back to the model, and the cycle repeats until the model stops requesting tool calls.

This article breaks down every component of this "agent loop" — from tool calling and loop control, to context management, permission sandboxing, and sub-agents — drawing on a YouTube technical walkthrough alongside both vendors' public documentation.

Tool Calling: The Model Can't Do Anything on Its Own

Claude Code's documentation is explicit: without tools, the model can only respond with text. What gives it the ability to actually act is the tool calling mechanism supported by both vendors' APIs.

Applications describe each tool using three elements: a name, a description, and a JSON schema defining the expected input format. Critically, the model never executes anything itself — per Anthropic's documentation, the model simply issues a structured request (such as calling a tool named search with a search pattern), the application runs it, and the tool result is passed back to the model.

OpenAI's function calling guide breaks this round-trip into five steps, ending with either a final reply or additional tool calls. The underlying logic is nearly identical across both vendors. This alternating "think–act–observe" pattern traces back to the ReAct paper by Shunyu Yao et al., presented at ICLR 2023, which specifically notes that thoughts (reasoning) don't change the environment and therefore produce no observations.

The ReAct (Reasoning + Acting) framework is essential background for understanding modern coding agents. Its core insight is interleaving the model's reasoning process (Thought) with external environment interactions (Action) to form a closed "think → act → observe" loop. Unlike pure Chain-of-Thought, reasoning steps in ReAct don't directly change any external state — only Actions trigger tool execution and produce observable results. This design lets the model dynamically adjust its plan based on real feedback at each step, rather than generating a complete sequence of operations upfront. The role of JSON Schema in tool definitions is also worth noting: it not only specifies input formats but serves as a contract through which the model "understands" the boundaries of each tool's capabilities — the model learns during training to generate valid call parameters from Schemas, giving tool calls verifiable structure.

Loop Control: Knowing When to Stop

The entire agent is built around a loop. Anthropic's documentation describes the client loop as a while loop driven by "stop reasons": as long as the stop reason is tool_use, execute the tool and continue; on any other stop reason, exit.

OpenAI's Agents SDK documentation describes its runner loop in nearly identical terms — if the output is final text with no tool calls, the run ends; otherwise, execute the tool calls, append the results, and call the model again. To prevent infinite loops, the SDK source code sets a default limit of 10 turns, throwing a max turns exceeded error when exceeded. Anthropic's server-side tool loop has a similar iteration cap.

In the video's toy simulation, this safeguard is clearly illustrated: a strategy that repeatedly re-runs tests without ever fixing the code can never complete the task, so the harness forcibly terminates it at the 10th call.

A Real Fix: 6 Model Calls From Start to Finish

The simulation uses a toy repository with 43 files and a single bug — a discount function that incorrectly multiplies by the discount rate instead of 1 minus the discount rate. The fix unfolds in a clear demonstration of how the loop operates:

• Call 1: Run tests, fail — the error message points to the applyDiscount function
• Call 2: Search for the function, locate it at line 9 of pricing.py
• Calls 3 & 4: Read the file, edit the return statement on line 10
• Call 5: Run tests again — they pass
• Call 6: Return plain text with no tool calls — loop terminates

The entire fix took 6 model calls and 5 tool calls. Even more telling is the context growth: the first call used roughly 300 estimated tokens (primarily the fixed system prompt and tool definitions), while by the sixth call the context had grown to approximately 870 tokens. Because the toy loop resends the full conversation each time, the 6 calls consumed roughly 3,700 tokens in total — this is exactly where real-world costs and latency come from.

Context Management: When the Codebase Won't Fit in the Window

The scale of real projects makes "read all the code in" impossible. The SWE-bench paper reports that its task repositories average 438,000 lines of code — far exceeding any model's context window. Even in the 43-file toy repository, reading every file would require roughly 15,000 tokens, 17 times the agent's final context. So the agent's strategy is to search first and read only the necessary file.

When approaching the context limit, both vendors have countermeasures. Claude Code's documentation describes clearing older tool outputs first, then summarizing the conversation if necessary. Codex's source code defines a token threshold that triggers automatic compaction — replacing history with a summary.

In the simulation's second task, which reads all 36 helper modules, the context would breach the toy window's 16,000-token limit by the 35th call without compression. With compaction enabled at a 75% threshold, the context drops from roughly 12,400 tokens to about 3,200 at the 26th call — reducing total tokens sent by around one-third.

On session management: Claude Code starts each new session with a fresh context window and reopens prior conversations when continuing or resuming a session. Codex's CLI source code similarly describes a resume command for restoring interactive sessions. Both support instruction files for loading project knowledge: Claude.md is loaded at the start of each session, while Agents.md is positioned as "a README for agents" — a format originating from collaborative work by OpenAI Codex, AMP, Google Jules, Cursor, and Factory, now maintained by the Agentic AI Foundation.

The context window is the maximum number of tokens a language model can process in a single pass; content beyond this limit becomes invisible to the model. Tokens are the basic unit of text processing — roughly 1–2 tokens per English word, similar for Chinese characters, and higher density for code due to symbols. Even GPT-4o's 128K token window can't hold 438,000 lines of code, which explains why agents must retrieve rather than ingest everything at once. Context compaction essentially trades detail fidelity for the ability to continue processing more turns — similar to how a programmer working on a long session retains key conclusions while forgetting intermediate reasoning. The choice of compaction threshold (e.g., 75%) directly determines the tradeoff between task success rate and API costs.

Permissions and Sandboxing: What's Allowed vs. What's Possible

Both Claude Code's documentation and Codex's source code define two independent layers of control: when permission must be sought, and what commands are technically capable of doing.

Claude Code lists six permission modes: Manual (ask before file edits and shell commands), Accept Edits (edit files without asking), Plan (explore and propose only, no source changes), Auto (a classifier intercepts high-risk operations), Don't Ask (reject anything that would trigger a prompt), and Bypass Permissions (documented as intended only for isolated containers and VMs). By default, its Bash sandbox restricts permissions to the working directory and related directories, with no network domains pre-approved.

Codex's source code defines three sandbox modes — Read Only, Workspace Write, and Danger Full Access — plus three approval policies: On Request, Granular, and Never. Its default preset is Workspace Write with On Request, and network access is disabled by default. At the OS level, both vendors use Seatbelt on macOS and Bubblewrap on Linux for isolation.

Seatbelt (macOS) and Bubblewrap (Linux) are kernel-level sandboxing tools that use macOS's Sandbox framework and Linux's user namespaces and Seccomp mechanisms respectively to achieve process isolation. Their core function is restricting the file system paths, network interfaces, and system calls a process can access — so even if an agent accidentally generates a dangerous command (such as deleting system files or exfiltrating data), the underlying kernel refuses execution. This is a second line of defense beyond permission prompts: the former is software-level intent filtering, the latter is OS-level capability constraint. The two controls operate independently, meaning that even in the most permissive mode (Bypass Permissions), hard sandbox isolation remains in effect — which is precisely why the documentation specifies that Bypass Permissions is "intended only for isolated containers and VMs," where the container itself already serves as an outer sandbox.

Sub-Agents: Divide and Conquer Complex Tasks

For large exploratory tasks, both tools introduce a sub-agent mechanism. Claude Code's documentation explains that each sub-agent runs in its own context window with its own system prompt, tool access, and permission settings, and returns only a summary to the parent agent. Its built-in sub-agents include Explore, Plan, and General Purpose.

Codex's source code defines built-in roles of Default, Explorer, and Worker, with role descriptions that even encourage dispatching multiple Explorers in parallel. In the simulation, the investigation task that read all 36 modules was run as a sub-agent — the sub-agent made 38 model calls within its own context, but when it returned, the parent agent's context was only about 370 tokens. This is precisely the value of sub-agents: isolating massive intermediate processes in a sub-context while keeping the parent context lean.

SWE-bench: The Ruler for Measuring Agent Capability

Objectively evaluating these tools requires a benchmark. SWE-bench was proposed by Carlos Jimenez et al. at ICLR 2024, comprising 2,294 real GitHub issue tasks drawn from 12 Python repositories. The model receives an issue and the codebase, produces a patch, and the evaluation system applies the patch and runs the tests.

Each task has at least one "fail-to-pass" test — one that fails before the fix and passes after. According to the scoring code, a task is only fully solved when all fail-to-pass tests pass and all originally passing tests (pass-to-pass) continue to pass. In the original paper, Claude 2 using retrieval alone (not an agent loop) solved just 1.96% of problems. The maintainers later collaborated with OpenAI Preparedness to release SWE-bench Verified — a 500-problem subset confirmed solvable by real software engineers.

SWE-bench's evaluation design reflects a core challenge in software engineering tasks: correctness verification depends on an existing test suite rather than human judgment. The fail-to-pass requirement ensures the patch genuinely fixes the problem; the pass-to-pass requirement prevents overfitting solutions that break existing functionality to pass new tests. This dual constraint makes SWE-bench far closer to real engineering scenarios than pure code generation benchmarks. The Verified subset's significance lies in filtering out problems in the original dataset that were ambiguous or flawed enough to stump human engineers too, making results better reflect a model's true capability ceiling rather than noise. The leap from Claude 2's 1.96% to today's top agent systems exceeding 50% also vividly illustrates the massive capability gains the agent loop delivers over single-pass retrieval.

The Agent Loop in One Sentence

Per both vendors' documentation, a coding agent is simply a language model wrapped in an execution harness: the model issues structured tool calls, the harness executes them and returns results, the loop repeats until the model stops calling tools. The SDK enforces a default turn limit, compaction and sub-agents manage context, instruction files inject project knowledge into the context, and permissions plus sandboxing are enforced by the harness.

Understanding this loop makes standards like MCP (Model Context Protocol) — which connects agents to external tools — much clearer. That's a thread well worth pulling further.