Ask Codex to find out why a login test is failing, fix it, and get the test passing again.

That request immediately creates a chain of work around the patch. Someone has to inspect the repository, locate the relevant files, run the test, read the failure, change the code, run the test again and decide whether the new result is good enough.

In a chat surface without direct repository and execution access, the model can still help with the reasoning, but the operator carries the surrounding work. Codex can inspect the repository, use the terminal, edit files and bring the resulting output back into the next step.

OpenAI’s name for the system around the model is the agent harness.

The knowledge cutoff for this article is 20 May 2026. Codex capabilities released after that date are deliberately excluded from the historical body of the article.

What sits around the model

The easiest way to understand a harness is to follow the work rather than the terminology.

For the login-test task, the model chooses what to do next. Context tells it what project it is in and what has already happened. Tools let it read, edit or execute. The workspace contains the code and tests. The result of each action comes back as new evidence.

That loop is what OpenAI unpacked in Unrolling the Codex agent loop in January 2026.

How the Codex Harness connects the model, tools, workspace and execution results

The diagram is intentionally simple. It is enough to notice where the model sits: in the middle of a system, not on its own. A strong model still matters enormously, but its usefulness as an engineering agent also depends on the context it receives, the tools it can call, the state it can inspect and the feedback it gets after acting.

OpenAI made another useful distinction on 4 February when it described the Codex harness and App Server. The web experience, CLI, IDE integration and desktop app could use the same underlying harness. Those surfaces change how a person controls Codex; they do not each need a separate definition of the agent loop.

There is plenty of architecture underneath that statement, but it is not needed to use the idea. For this article, the harness is simply the part that joins reasoning to real work.

Three agents make isolation concrete

Scale the same workflow to three jobs at once. One agent is fixing authentication, another is upgrading dependencies, and a third is changing the settings page.

Without isolation, all three can end up looking at the same half-finished working directory. A test run for one task may contain changes from another. Review gets harder because the final diff no longer maps cleanly to the job that produced it.

That is where Git worktrees stop feeling like Git trivia.

Codex dispatching parallel agents into separate isolated worktrees

When OpenAI launched the Codex app on 2 February 2026, multi-agent work and isolated worktrees were presented together. The pairing solves a practical coordination problem: parallel agents need separate places to work, and humans need a clean way to inspect what each one changed.

The same launch also put threads, diff review, Skills and Automations into the desktop experience. There is no need to teach all four here. Their presence points in the same direction: Codex was becoming a place where engineering work could be assigned, resumed, inspected and repeated, rather than a place that merely returned snippets of code.

The Git mechanics deserve their own article. The useful idea here is simpler: a worktree is an isolation boundary for a piece of parallel work.

The command centre is where the human comes back in

Parallel work creates one more problem: someone still has to supervise it. OpenAI called the Codex app a command center for agents. That phrase is useful because it describes the human side of the system.

When the agent can handle file edits, commands and test runs, the human does not need to operate every step manually. Attention shifts upwards. Which task should run? Has an agent gone off course? What changed in the diff? Does a sensitive command deserve approval? Is the result ready to accept?

This is close to the line OpenAI used in its February Harness Engineering work: Humans steer. Agents execute. It is not an argument for removing people from engineering. It is a different allocation of attention.

That allocation only works when the environment produces useful signals. Repository instructions, tests, CI, documentation and observability stop being background furniture. They tell the agent what good work looks like and give it feedback when something goes wrong.

The same point matters on long tasks. Important state can live in a spec, a plan, the repository, test output or other artefacts that the agent can read again later. Treating the model’s context window as the only place where project state may live would be a very brittle way to work.

Tools need boundaries, and engineering work needs evidence

Once the harness can act on the repository, execution boundaries stop being an abstract safety topic. The same access that removes manual work also increases the blast radius when the limits are vague.

OpenAI’s 8 May article, Running Codex safely at OpenAI, separated two controls that are often blurred together. Sandboxing constrains the execution environment, including writable locations and network access. Approval determines when the agent must stop and ask before proceeding.

A model may know exactly how to run a command. That does not mean the surrounding system should grant the command automatically.

The same discipline applies at the other end of the task. An agent saying done is not much of an acceptance test. Engineering work gives us better evidence: test results, build output, diffs, command output and explicit acceptance criteria. A harness that can return those signals to the model makes self-correction possible; returning them to the human makes review possible.

Hooks attach checks to lifecycle moments; they do not create a new authority layer

Hooks reached general availability on 14 May. That gave the workflow a practical place to attach validators, secret scans and other existing rules to defined lifecycle points.ChatGPT & Codex changelog

Suppose a team already expects a secret scan after a class of change. A Hook can make that check appear at the relevant lifecycle moment instead of relying on somebody to remember to add another sentence to every prompt.

That is not quite the same job as a Skill. A Skill gives the agent a reusable procedure for handling a class of work. A Hook is closer to “when this lifecycle event happens, run or trigger this check”. The two can complement each other without being interchangeable.

A Hook is not a correctness certificate either. Seeing that a validator ran proves that the validator ran. Whether the result is good enough still depends on what it checked and what it returned. Attaching a check to the lifecycle does not turn an agent’s done message into trustworthy completion evidence.

This fits the harness model neatly. The harness does not only connect reasoning to tools; it can also bring repository checks into the workflow at the right moments. Correctness still comes back to tests, builds, diffs, validator output and acceptance criteria.

By the same 14 May milestone, the control surface was beginning to move away from the machine doing the work. OpenAI showed a mobile Codex preview where a user could inspect threads, terminal output, diffs and test results and steer work remotely. Hooks and that remote preview are the last milestones used here. Anything released after 20 May stays outside the historical body of this article.

The first five months of 2026 tell one story

Read as release notes, the first five months of 2026 look busy: an agent loop article, the desktop app, worktrees, browser and computer use, sandboxing, approvals, remote supervision and Hooks.

Placed on one line, they tell a cleaner story. Codex was filling in the system around the model: execution, isolation, shared runtime, engineering feedback, broader tools and clearer control boundaries.

Key public milestones that explain how the Codex harness took shape by 20 May 2026

The vertical line at 20 May is an editorial boundary, not the end of Codex development. It keeps a historical article honest about what was publicly available at the time.

That leaves a more useful way to judge a coding agent than asking for the model name alone. Look at the context it receives, the tools it can call, where state lives, how parallel work is isolated, what requires approval and what evidence comes back before the task is accepted.

The model remains one of the most important parts of the system. The day-to-day Codex experience comes from the way that model is joined to the repository, execution environment, permissions and feedback around it.

The next article moves from this system view to everyday operation: Plan, steering, and how to choose between the different Codex surfaces.

References