Coding Agent Harness Explained: The 7 Parts That Decide Safety

Ask most teams how their coding agent works and you will hear about the model. Which one, how smart, how many tokens. That is the wrong place to look first. The model proposes the next step. The harness decides whether that step runs, where it runs, what it can touch, and what the agent remembers afterward. When an agent deletes the wrong folder, leaks a credential or burns budget in a loop, the harness is almost always where the failure lives.

This guide explains a coding agent harness in plain terms, walks through the seven parts that most of the major tools share, and ends with a checklist you can run against your own setup this week.

What a coding agent harness is

A coding agent is two things. The model reads context and returns text or tool calls. The harness is everything else: the loop that sends context to the model and runs the tools it requests, the permission layer that approves or blocks each call, the sandbox the commands execute in, the logic that trims history when the context window fills, and the connectors to outside systems.

Research on production coding tools now uses this split as the working abstraction. A 2026 source-code study of eleven harnesses, including Claude Code, Codex CLI, Gemini CLI and Aider, found the same core subsystems in each. The differences between products are mostly differences in how those subsystems are built, not in which model sits underneath.

That is the first practical point: two agents on the same model can behave very differently. The harness is the product.

The seven parts

1. The loop

The loop is simple: send context, read the reply, run any requested tools, append the results, repeat until the model stops asking for tools. The loop itself is a few hundred lines. What varies is the stop condition. A good harness caps turns, detects repeated failing actions and surfaces a clear reason when it gives up. A weak one keeps spending tokens on the same broken test.

Check it: Does your agent have a turn or cost ceiling that stops it without a human? If the answer is "we rely on the model to stop," you do not have a limit.

2. Tools and their shape

Tools are the verbs the model can use: read a file, edit a file, run a shell command, search the web, call an MCP server. Each tool's description and schema is part of the prompt, so every tool you add also adds cost and attack surface.

Fewer, well-scoped tools beat many broad ones. A shell tool that can run anything is the largest surface you will ever grant, and it is the one that most often appears in incident reports.

Check it: List every tool the agent can call, including tools inherited from MCP servers and plugins. Remove the ones you cannot justify in a sentence.

3. Approvals and permission modes

Approvals decide which calls pause for a human. Most tools offer a spectrum: ask for everything, auto-accept file edits but ask for shell commands, or run fully autonomous inside a sandbox. Each step up trades friction for risk.

The mistake to avoid is treating approval as a yes-or-no switch set once for a whole team. The safer pattern is to match the mode to the task: stricter for production repositories and credentials, looser inside a disposable worktree.

Check it: Write down which mode your team uses for each kind of repository. If the answer is the same everywhere, that is the finding.

4. The sandbox

The sandbox limits what a command can reach: which directories it can write, whether it can open network connections, and which environment variables it inherits. This is the layer that turns a mistake into a contained mistake.

Sandboxes have been the area of most rapid change. For a deeper look at how these boundaries fail in practice, see AI coding agent security. In October 2026, Claude Code shipped a release that fixed more than ten routes around its sandbox and permission checks, including shell startup files that ran outside the sandbox and symbolic links that bypassed write-deny rules. Codex hardened its own sandbox checks and began masking credentials in remote shell sessions. The lesson is not that one tool is unsafe. It is that a sandbox is code, and code has bypasses.

Check it: Confirm the sandbox denies writes outside the project and blocks reading your home-directory secrets. Test it with a harmless attempt to write to a path outside the repo and watch whether it is refused.

5. Context management and compaction

Every model has a fixed context window, and a long session fills it. Harnesses respond in one of three ways: they truncate the oldest history, they summarize it (compaction), or they move work into subagents with fresh context. Each choice changes what the agent remembers and what it quietly forgets.

Compaction is useful and dangerous in equal measure. A summary can drop a constraint you stated at the start, such as "do not touch the billing module." The fix is to keep durable rules in a project instruction file rather than in the chat, where compaction is less likely to erase them. Long sessions also cost more per turn, which is why cheap subagent architecture matters as much as the summary itself.

Check it: Put one hard rule in your project instruction file, start a long session, and confirm the agent still follows it after a compaction.

6. Edit formats

The harness decides how the model expresses a change: a whole-file rewrite, a search-and-replace block, or a unified diff. This matters for two reasons. Whole-file rewrites are slow and can silently delete code the model did not mean to touch. Diff formats are precise but fail when the file has changed under them.

Good harnesses validate an edit before applying it and write atomically, so a crash never leaves half a file on disk.

Check it: After a session, review the diff rather than the chat summary. The diff is what shipped.

7. Extensions: MCP servers and plugins

The Model Context Protocol lets an agent call external servers for data and actions. It is powerful and it is the fastest-growing part of the attack surface. Every MCP server you connect runs with the agent's permissions and can return text that the model then treats as instructions.

Treat MCP servers like dependencies. Pin versions, review what each one can do, and do not let a developer add one to a shared config without review. Instruction files that the agent loads automatically, such as AGENTS.md, deserve the same caution: recent security research showed that a malicious instruction file in a working directory can steer an agent into installing packages or exposing tokens.

Check it: List every connected MCP server and plugin. For each, note the version, the data it can read, and who approved it.

A four-point audit you can run this week

If you only have an afternoon, run these four checks on your current setup:

1. Limits: Does the agent stop on a turn or cost ceiling without a human? If not, set one.
2. Reach: Can it write outside the project and read your home-directory credentials? Test both.
3. Memory: Are your hard rules in a project instruction file, not only in chat? Verify one survives a long session.
4. Extensions: Is every MCP server and plugin listed, versioned and approved? Remove any you cannot name an owner for.

Failing any one of these does not mean your agent is unsafe. It means the harness is making a decision you have not made on purpose.

Common pitfalls

• Trusting the chat summary. Review the diff, not the narration. The diff is what ships.
• Setting approval once for the whole team. Match the mode to the repository's risk.
• Adding MCP servers without an owner. An unowned server is an unreviewed dependency.
• Keeping rules only in chat. Compaction can erase them; move them into a project instruction file.

Where this leaves you

The model will keep improving, and the gap between the top models will keep narrowing. The cost side of that trade-off is covered in the harness tax. The harness is where your team's real choices live: what the agent may touch, how long it may run, what it remembers, and what it may install. Judge a coding agent by those seven parts rather than by a benchmark, and run the audit before you expand its access.

If you are evaluating tools this quarter, start with the sandbox and the extension list. Those two decide the worst-case outcome, and they are the fastest to check.

Frequently asked questions

What is a coding agent harness?

The harness is everything around the model in a coding agent: the loop that runs tools, the permission layer, the sandbox, context management, edit handling and extensions. The model proposes the next step; the harness decides whether it runs and where.

What should I check first in my coding agent setup?

Start with the sandbox and the extension list. Confirm the agent cannot write outside the project or read home-directory credentials, and that every MCP server and plugin is listed, versioned and approved.

Why does context compaction matter for coding agents?

Compaction summarizes older history to fit the context window, and a summary can drop constraints stated early in a session. Keep durable rules in a project instruction file so they survive compaction.

Does a better model make a coding agent safer?

Not by itself. A stronger model improves judgment, but limits, sandboxing and approvals are enforced by the harness. A safe setup with an average model usually beats an unconstrained setup with a top model. e model usually beats an unconstrained setup with a top model. ile so they survive compaction.

Does a better model make a coding agent safer?

Not by itself. A stronger model improves judgment, but limits, sandboxing and approvals are enforced by the harness. A safe setup with an average model usually beats an unconstrained setup with a top model. make a coding agent safer?

Not by itself. A stronger model improves judgment, but limits, sandboxing and approvals are enforced by the harness. A safe setup with an average model usually beats an unconstrained setup with a top model.