Harness
A built for one project that calls the as a worker. See what it is, how it works, how it is used and what to watch for, with pictures and examples.
In one sentence
Every ordinary sent to or uses the , even when the answer is immediate and no is called. A prompt triggers the harness; it is not itself the whole execution system. 's broader definition also includes system prompts among harness components.
- Think of it like this
- Think of a kitchen: even a small order uses the kitchen's working setup.
- Example
- Send a greeting to Codex. Input → → answer is already a path through the harness's loop.
- Common mistake
- Using a harness does not require or repeated attempts. A user prompt and the harness that processes it have different roles.
The harness in three sources
1. Codex: a prompt starts the harness's agent loop
the Codex harness, which provides the core agent loop and execution logic that underlies all Codex experiences
OpenAI — Unrolling the Codex agent loop
describes the Codex harness as providing the core agent loop and execution behind every Codex experience. Even a short input starts that loop. In the diagram, USER INPUT leads to MODEL INFERENCE, then either AGENT RESPONSE or TOOL CALLS followed by another inference. A direct answer also passes through this loop. Therefore, every ordinary Codex prompt uses the harness; the prompt is the input that triggers it.
Even one word, "hello", goes through the harness
Type just hello into Codex. The model greets you back without using a single tool, and it is over. That makes it easy to think "this time the harness was not used". Follow the four steps below, though: that short exchange has already gone once around the agent loop.
-
Type hello You
-
Build the prompt Harness
-
Model inference Model
-
Show the reply, end Harness
With a tool call: run it, add the result, back to step 3. hello ends after one round.
-
Type helloYou
You type hello in the . This is only the user input. Nothing has run yet.
-
Build the promptHarness
The harness does not send hello on its own. It adds the system instructions, (if there is one), the list of tools the model may call and the conversation so far, and sends all of it to the model as one prompt.
-
Model inferenceModel
The model reads the prompt and decides that a greeting needs no tool. So it writes only a reply such as "Hi! What can I help you with?". There is no tool call.
-
Show the reply, endHarness
The harness checks the model output for tool calls. There are none, so it shows the reply on the screen and ends this . Had there been a tool call, the harness would have run the tool, added the result to the prompt and gone back to step 3.
2. Claude Code: the harness supplies the means to act
The tools, context management, and execution environment that turn a language model into a capable coding agent. Claude Code is the harness; Claude is the model inside it. The harness supplies file access, shell execution, permission gating, memory loading, and the loop that chains actions together.
Claude Code — Glossary: Agentic harness
defines the harness as the tools, and execution environment that make a a . Claude Code is the harness; is its model. File access, execution, checks, and the loop connecting actions come from the harness. A short request can use these capabilities as needed, so a simple prompt also uses the harness.
3. LangChain: everything around the model
If you're not the model, you're the harness.
A harness is every piece of code, configuration, and execution logic that isn't the model itself. A raw model is not an agent. But it becomes one when a harness gives it things like state, tool execution, feedback loops, and enforceable constraints.
LangChain — The Anatomy of an Agent Harness
In this article's broad definition, everything in the agent system except the model itself belongs to the harness: its , configuration and execution logic. A model becomes an agent when this surrounding system supplies state, tool execution, feedback and enforceable constraints. The article includes:
- System prompts.
- Tools, , MCPs and their descriptions.
- , sandbox and infrastructure.
- spawning, and model routing.
- and for , continuation and checks.
This perspective focuses on designing systems around model intelligence. System prompts are part of that design; a user's prompt is input processed by the system.
Models and harnesses grow together
Model and harness design evolve together. LangChain explains that products such as Codex and Claude Code use models and harnesses together during , improving file operations, bash, planning and subagent work. Useful capabilities enter the harness and then the next model's training. Models become more capable in that environment, but changing tool logic can also lower performance. This is the article's account of their co-evolution.
Three faces of the harness
The harness built into a coding agent, the harness a project builds itself, and the work of building good harnesses — see each one in its tab.
Learn it in the AI Course too
What it is
A built-in harness is the wrapped around the inside a such as or . The model only reads and writes text; the gives it tools such as reading files, editing and running commands, adds instructions like AGENTS.md or CLAUDE.md, asks for and runs the loop. In each step the model either answers you or asks for a . For a tool call, the harness runs the tool, adds the output to the and asks the model again, until the model gives a final message. The harness also manages the , for example by compacting a long conversation into a shorter summary.
In plain words A cook who cooks, tastes and says "delicious" all alone.
How it works
-
You send a request
-
The model asks for a tool
-
Harness runs it, returns the output
-
Repeat until the final answer
How to use it
-
AGENTS.mdandCLAUDE.mdthe harness puts these project instructions into the prompt for you. Codex reads
AGENTS.md; Claude Code readsCLAUDE.mdand can also readAGENTS.md. -
/compactwhen the conversation gets too long, the harness summarizes it so the work can go on.
-
Permissions and sandbox — in Claude Code,
Shift+Tabchanges what may do without asking; in Codex, the sandbox decides what its shell tool may touch. -
Escin Claude Code, stop the loop at any moment and steer the another way.
Watch out
The same program does the work and decides that the work is finished, so check it yourself by reading git diff and running the tests again. In Codex the sandbox covers only Codex's own shell tool; tools from must enforce their own guardrails. Do not confuse it with a , which is an outer a project writes itself to call the agent.
Examples
-
codexstart it and make a request — Codex writes and tests -
~/.codex/sessions/the session log Codex keeps
Related terms
Original and official docs
This page explains the term in plain words. The original is the authority: if they differ, follow the original.
- See this term in the originalUnrolling the Codex agent loop OpenAI · checked 2026-10-24
- Anthropic — Claude Code docs: How Claude Code works — The agentic loop(opens in a new window)
- Anthropic — Claude Code docs: Glossary — Agentic harness(opens in a new window)
- OpenAI — Unlocking the Codex harness(opens in a new window)
- Anthropic — How Claude Code works(opens in a new window)
What it is
A project harness is a small that one project writes for itself, such as a script or a script. Instead of a person typing in a chat, the runner calls or in non-interactive mode with codex exec or claude -p and gives it one task. The works like a hired worker and returns its answer, then the runner checks the result with the project's own tests and keeps a log. So the agent does the work, but the project, not the agent, decides whether the work passes. Inside each worker call, the agent's still runs as usual.
In plain words An who tastes, weighs and records every plate the cook sends out.
How it works
-
Runner picks the next task
-
Calls or claude -p
-
Project tests check the result
-
Save the log, then repeat
How to use it
-
codex exec "<task>"progress goes to stderr and only the final message goes to stdout, so the runner can save it easily; add
--jsonto get a stream of events. -
codex exec --sandbox workspace-writecodex execruns in a sandbox by default; this option lets the worker edit files in the workspace. -
claude -p "<task>" --output-format jsonreturns the result, session and cost as , and exits with 0 on success or non-zero on failure; add
--bareto skip that machine's hooks, skills and CLAUDE.md for the same run everywhere. -
harness/build-log.mdthe Cookbook example keeps one plan file per phase under
harness/build/and records each phase's checks in this build log.
Watch out
The runner hands the agent real power, so give only the it needs and use danger-full-access only in an or runner. A claude -p run shows no trust dialog, and in Manual mode a call that needs approval is denied unless something approves it, so list the tools it may use with --allowedTools. A project harness does not replace the built-in harness; it wraps it from the outside.
Examples
-
bash harness.sh "<request>"pass any request to the runner -
codex exec --json --sandbox read-onlythe worker the runner calls -
bash harness.sh verifycheck the evidence and the result again
Related terms
Original and official docs
This page explains the term in plain words. The original is the authority: if they differ, follow the original.
- See this term in the originalCodex Docs — Non-interactive mode OpenAI · checked 2026-10-20
- OpenAI — Codex non-interactive mode — Basic usage(opens in a new window)
- Anthropic — Claude Code docs: Run Claude Code programmatically — Get structured output(opens in a new window)
- OpenAI — Iterating development workflows with Codex — Create harness and build phase files(opens in a new window)
- OpenAI — Harness engineering: leveraging Codex in an agent-first world(opens in a new window)
- Anthropic — Claude Code non-interactive mode (claude -p)(opens in a new window)
What it is
Harness engineering is the name gave to a new kind of engineering work in an article about building a product with . Over five months a small team shipped an internal beta with zero lines of hand-written : about a million lines and roughly 1,500 merged , starting with just three engineers. Their rule was "Humans steer. execute." The engineers' job moved from writing code to designing the environment, stating the intent and building so Codex agents can do reliable work. When the agent got stuck, they did not ask it to try harder; they asked what capability was missing and how to make it legible and enforceable for the agent.
In plain words Instead of cooking yourself, you design the kitchen, the recipes and the checks.
How it works
-
Give agents a short map
-
Keep all knowledge in the
-
Enforce rules with and tests
-
Clean up drift continuously
How to use it
-
AGENTS.mdkept short, about 100 lines, as a table of contents that points into a structured
docs/folder instead of a 1,000-page manual. -
Custom linters and structural tests — enforce architecture rules such as fixed layers and dependency directions, and the lint tell the agent how to fix the problem.
-
Legible app — every can boot its own copy of the app, and Codex reads the through the plus logs and metrics, so it can and check fixes.
-
Golden principles and cleanup tasks — background Codex tasks scan for drift and open small refactoring pull requests, like garbage collection that pays down technical debt a little at a time.
Watch out
OpenAI says this behavior depends heavily on the structure and tooling of that one repository and should not be assumed to work elsewhere without similar investment. They also say they do not yet know how architectural coherence holds up over years in a fully agent-generated system. Their fast merging with few blocking gates would be irresponsible in a low-throughput team, as the article itself notes.
Examples
-
AGENTS.mda short map that points to the docs -
docs/designs, plans and quality notes kept in the repository
Related terms
Original and official docs
This page explains the term in plain words. The original is the authority: if they differ, follow the original.