Context, Permissions, and Network Overhead Define Agent Performance
OpenAI’s Dominik Kundel argues that an agent’s practical capabilities depend as much on its harness as on its model: the surrounding system determines how context is assembled, which tools are available, what actions require review, and how work persists across turns. In Codex, that means deferring tool definitions to protect context, matching file and shell interfaces to model training, and using constrained review agents for sandbox escalations. As inference accelerates, Kundel says, the harness must also reduce network overhead through stateful WebSocket transport and manage long-running work through explicit goals and context compaction.
The harness determines what an agent can know, do, and retain
Dominik Kundel describes Codex as a harness around model inference: the layer that constructs context, exposes tools, manages permissions, carries state between turns, and decides how an agent continues over time. The model performs inference; the harness determines much of what the model can see, do, preserve, and escalate.
Codex separates this work across two protocols. The app server connects a user interface to the harness, while the Responses API connects the harness to inference. Kundel says the app server is an open boundary: builders can place another UI or agent interface on top of Codex while retaining the harness’s functionality. He cites third-party projects, a plugin that puts Codex into Claude Code, and a Doom integration built using the same protocol.
The Responses API is presented as a redesign of chat completions for agentic work, with built-in capabilities including web search, image generation, tool search, and compaction. Kundel says OpenAI worked with partners including Ollama, LM Studio, and Nvidia on an open Responses schema, intended to let Responses-compatible model providers plug into the Codex harness.
The implementation is available in the openai/codex repository. The repository shown during the presentation identifies Codex as a lightweight terminal coding agent under an Apache-2.0 license, and Kundel says the harness is written in Rust. Teams can run it, study it as a reference architecture, or fork it.
Context has to be small enough to reason over and stable enough to cache
The first major job of the harness is context construction. Kundel gives it three competing requirements: size, flexibility, and cacheability.
Size is not solely a cost problem. A larger context consumes more tokens, but it can also make the model less reliable when it contains too much irrelevant or contradictory material. Flexibility pulls in the other direction: different users may have different skills, plugins, and MCP integrations, each of which can enlarge the tool registry or other variable portions of the prompt. Cacheability is the third constraint, because stable prompt components help with both cost and latency.
Some context is predictable. Model instructions, for example, are structured and do not change substantially in size. Other components are inherently variable: installed tools, MCP-provided capabilities, and the list of skills available to the agent. Kundel’s Nano Codex debugging interface breaks the assembled input into model instructions, tool registry, permissions and runtime, and available skills—making visible the material the model receives before it chooses an action.
Codex manages that variability partly through deferred tools. A deferred tool is not inserted directly into the context window. Instead, the model can discover it later through tool search, when it has reason to think the capability is needed. Kundel says this is available through the Responses API: since GPT-5.4, a builder can mark tools for deferred loading and use OpenAI’s tool search or provide a custom discovery mechanism.
A CRM example illustrates the intended structure. A namespace can tell the model that a set of tools concerns customer lookup, while individual functions—such as list_open_orders—remain deferred until requested through search. The model gets enough high-level organization to know when to seek a tool without receiving every function definition in every turn.
Codex also caps the available-skills list at 2% of the maximum context window. As that list grows, the harness progressively shortens the descriptions included in it.
The policy is an attempt to preserve reach: a user can install a large and changing capability set without requiring every capability’s full definition to be present in every model turn.
Tools work best when their interfaces match the model’s training
An agent’s usefulness depends on action, and Kundel groups common actions into three categories: asynchronous work, computer or browser use, and filesystem interaction.
For asynchronous work, Codex gives the main agent a spawn agent tool. It can create separate agent instances, send them follow-up input, wait for them, or shut them down. The same basic pattern supports background terminals: the agent can start a terminal process, continue with other work, supply data through standard input, and wait for completion when needed. In the example shown, a main agent delegates exploration tasks to two subagents in parallel.
For browser work, Codex uses code execution rather than relying only on a fixed vocabulary of discrete actions. It maintains a persistent Node REPL—an interactive session that retains state between commands—across turns, and the model writes Playwright-style JavaScript against a browser instance. Once the agent has found the relevant page or opened a tab, later turns can refer back to that environment. Kundel says the model can inspect a page’s structure and then script repeatable work, such as extracting information across subsequent pages, more efficiently.
Filesystem work follows the affordances on which the models were trained. Recent models beginning with GPT-5 were trained to edit files through an apply_patch tool, supplying a diff for modifications and using the same mechanism to create files. For searching and navigation, Codex relies on a shell tool. Kundel says the models naturally reach for ripgrep, so the harness ships it when it is not already installed. On Windows, models trained for the environment use PowerShell instead.
That pairing of model behavior and runtime matters. Patch-based edits, shell navigation, bundled search tooling, and platform-specific command behavior make the action surface resemble the environment the model has learned to operate in rather than a generic filesystem abstraction.
Reducing approval fatigue without turning off the guardrails
All filesystem interaction in Codex passes through a sandbox layer. On macOS, Dominik Kundel says Codex uses the built-in Seatbelt mechanism; on Linux, Bubblewrap; on Windows, the team built a custom open-source native sandbox. The Windows implementation is included in the Codex repository.
Sandboxing creates a familiar usability problem: repeated approval requests can push users toward full-access mode. Kundel acknowledges the appeal of that choice for long-running tasks, but says OpenAI’s security team does not want users to solve approval fatigue by broadly disabling controls.
The more difficult question is whether a specific escalation is authorized in its actual context. A high-agency agent can take actions that are technically plausible but not what the user intended. Kundel offers two examples: an agent asked to email a file might be unable to attach it and decide to upload it to a file-sharing service instead; an escaping error might cause deletion of more data than intended. Better models do not eliminate such cases, especially when prompting encourages agency.
Codex’s answer is an auto-review subagent. When a task encounters an action that needs to escape the sandbox, the harness can start a separate reviewer with read-only permissions and no ability to create additional subagents. It receives guidance on authorization and risk, along with the transcript and the specific tool calls under review. It then produces a judgment based on factors including user authorization and the impact of the requested action.
The transcript is essential because the same operation has different meaning in different circumstances. If the user explicitly asks the agent to delete a local README.md, the review can treat that as a narrow and readily reversible workspace change. The displayed review returns allow, with a low risk level and high user authorization. But an unprompted attempt to delete a .git directory should not be treated as equivalent, because it could erase project history the user never asked to remove.
If you ask it to delete a .git folder, great. If you didn't ask it to, it should probably not touch that part and like completely delete your history.
Kundel says auto-review is intended to handle harder-to-predict actions automatically during long runs while keeping data exfiltration outside its scope. The distinction applies beyond local files. A network request to check whether internet access works may be acceptable, while uploading a file is a categorically different operation.
Once inference is fast, protocol overhead becomes the limiting system
Dominik Kundel argues that inference speed changes where the harness needs to optimize. When GPT-5.3-Codex-Spark ran on Cerebras at more than 1,000 tokens per second, he says, inference ceased to be the primary bottleneck in tool-heavy workflows. Network overhead became the limiting factor.
The problem compounds in an agent loop. An agent can call a tool, receive a result, call another tool, and repeat. If every quick turnaround requires a new HTTP interaction and a replay of the full conversation state, the system spends increasing time on connection and payload overhead rather than on inference or tool execution.
Codex addresses this with a WebSocket mode for the Responses API. Rather than using server-sent events over HTTP, it keeps a persistent WebSocket connection open. That removes repeated connection handshakes and makes the exchange stateful: after a tool call, the client sends back the tool result rather than resending every preceding item in the conversation.
A side-by-side Nano Codex demonstration contrasts an HTTP “full replay” with a WebSocket “incremental” exchange. In the example, the HTTP path sends nine items back while the WebSocket path sends one updated item. Persistent, stateful transport removes both handshake and full-replay overhead from tool-heavy loops.
With all of these tool calls and the interactions, inference was no longer the bottleneck. It was actually the network.
Long-running work depends on explicit completion and controlled memory
Dominik Kundel explains Codex’s /goal mechanism as a harness-controlled continuation loop. The user sets a goal; the harness builds turn input and runs the agent; if the goal remains active, it injects a continuation prompt containing the objective. This repeats until the model calls an update goal tool to report that the plan or objective has been achieved.
That design is why Kundel recommends concrete, measurable goals over elaborate essays. The loop needs a condition that the model can recognize and report as complete. A task such as guessing a number can be operationalized with an end state; a long, ambiguous goal statement is harder to verify.
For work that lasts hours or days, the context itself must also be managed. Kundel says Codex uses server-side auto-compaction, introduced at the end of the prior year, to replace a previous context window with a new one containing an opaque compaction item that preserves necessary information for later turns. Compaction can be triggered manually, automatically when thresholds are met, or by the harness itself.
The mechanism is intended to preserve the information needed for subsequent turns without retaining the full prior conversation in its original form. Kundel says Codex uses automatic server-side compaction in a form the model was trained with so that long-horizon performance remains consistent.