Harnesses

Eighty minutes, five sections. Section one is definitions; if the room already lives in a coding harness, move quickly. Section two is the long one, because the plumbing is where the money and the risk are. Section three is the only place product names appear. Sections four and five are decisions and homework. The rule for today is a line from Part I; it has aged well.

The word “harness” started as engineering slang and is now in vendor documentation, so it is worth a precise definition. A harness is everything in the system that is not the model: the code, configuration and policy that turn a text predictor into something that does work. Addy Osmani’s April 2026 essay puts it as “every piece of code, configuration, and execution logic that isn’t the model itself”, and Microsoft now uses the word for the execution engines inside Copilot Studio. Six parts cover it. The model predicts tokens and does nothing else; it is the only part that is AI, and it is the part you rent. Context is whatever is placed in the window on each call: standing instructions, the rules file for this project, the files it has read, the conversation, the results of tools. The loop is decide, act, observe, check, run again until done or stopped; the harness runs that loop and the model only fills in the deciding step. Tools are code the harness runs on the model’s request: a shell, a file editor, a browser, a search engine, your ticketing system. Memory is whatever survives the end of a session, which may be nothing. Policy is the leash: what needs a human’s yes, what runs inside a sandbox, when to stop. Part III drew the same anatomy for agents with slightly different names; this is the same picture with the body named. Keep the colours: gold is the model, blue is code that acts, coral is a human or a limit.

The cleanest public evidence that the harness matters as much as the model comes from Anthropic’s own engineering team. In March 2026 they published “Harness design for long-running application development”. The same model was given the same job, to build a complete web application, two ways. Run bare, one prompt in a single context, it took about twenty minutes, cost about nine dollars, and produced an application that did not work. Run inside a harness with three roles, a planner that expanded the short prompt into a product specification, a generator that built it, and an evaluator that drove the running app in a browser and graded it against written criteria, it took about six hours, cost about two hundred dollars, and produced a working, far more complete product. The second half of the story matters just as much. When a newer model arrived, the team removed part of the harness: the sprint structure went, and the evaluator was kept only for work beyond what the model could do reliably alone. Their line is the one on the slide: every component in a harness encodes an assumption about what the model cannot do on its own. That is why two products on the same model behave so differently, and why harness design does not go away as models improve; it changes shape. Part II said “which model?” is half the question. This is the evidence.

Part III drew the agent loop from the model’s point of view: decide, act, observe, check. It is the same loop, but drawn from the harness’s side it looks different and it is more useful. First the harness assembles the context: it reads the rules file, pulls in whatever memory it keeps, adds the task and everything that has happened so far, and sends the lot to the model. The model reads the window and writes one message, which is either a request to use a tool (“run the test suite”, “replace these lines in this file”, “fetch this page”) or a statement that it is finished. That request now hits the gate: is this tool allowed at all, does this action need a human’s yes, will it run inside a sandbox, is the step or spend budget exhausted? Only if the gate says yes does the harness run the tool, with the tool’s permissions, not the model’s, because the model has none. The result is turned into text and appended to the window. The harness then checks: done, stuck, over a limit, or go round again. Four of the five boxes are harness. The model writes one message per turn and never executes anything. That is why the fix for most “the AI did something stupid” stories is in the gate and the tool permissions, and why the slide for section two on permissions is the most important one in the deck. Claude Code’s documentation describes exactly this cycle and calls the harness-side pieces permissions, hooks and sandboxing.

This ladder is a teaching device, not an industry category. It exists so that people can place the thing they used this morning. Rung one is a chat box: a model, a window and a send button. You run the loop by reading the answer and typing again. Rung two is the same box with a few tools bolted on: web search, a code runner, file upload, a “memory” feature that pastes notes back into the window. It is a harness, a thin one, and you do not configure it. Rung three is a coding session: Claude Code, Codex, Gemini CLI, OpenCode and their relatives. The harness has a shell, an editor, your test suite, and a permission prompt that asks before it does anything that changes the world. It ends when you close the terminal. Rung four is an operator: Hermes or OpenClaw. It lives on a machine you own, answers you on Telegram or Slack, runs jobs on a schedule, and keeps a profile of you across months. Rung five is a built product: your own harness assembled on an SDK, or an agent inside software you already pay for; in both cases the loop belongs to someone’s code and your tools are plugged into it. The two arrows at the bottom are the trade. To the left there is nothing to configure and nothing to break. To the right you get persistence and channels, and the permissions to get wrong. Most organisations are on rungs two and three, and should be.

Part III showed one tool call in a support agent. Here is the same mechanism in a coding harness, because it is the mechanism everything else in this section hangs off. A tool, in this world, is a function with a description: a name, a sentence about what it does, and the arguments it takes. The harness puts the list of available tools into the context window. When the model wants one, it does not call anything; it writes a small piece of structured text, usually JSON, saying which tool and which arguments. The harness reads that text, checks it against policy, and if allowed, runs the real function with the real permissions: the test runner, the file editor, the database client. The output is converted to text and appended to the window, and the model reads it and writes its next request. Three consequences. The model never touches your systems; it only ever produces text. Whether that text becomes an action is the harness’s decision, which is why the gate on the previous slide is where control lives. And the tool’s permissions are the actual security boundary: a tool that can delete gives the agent the ability to delete, whatever the prompt says. Part III put this as “prompts are suggestions; permissions are walls” and it is the single most useful sentence in the series. The trace on the slide is invented; real ones in Claude Code, Codex and the others look like it, and you should read one before you trust anything.

Before MCP, every harness had its own way of describing tools and every system you wanted an agent to use needed a custom integration per harness. The Model Context Protocol fixes the N-times-M problem the way USB-C fixed cables, which is the protocol’s own analogy. An MCP server is a small program that sits in front of one system, your CRM, your database, your file system, Sentry, and publishes three things: tools (actions the model can request), resources (data it can read) and prompts (reusable templates). An MCP host, which is the harness, connects to one or more servers, discovers what they offer with a list request, and calls them with the same JSON tool-call mechanism as the previous slide. Local servers run on your machine and talk over standard input and output; remote servers talk over HTTPS and use OAuth for login. Anthropic released MCP in November 2024 and on 9 December 2025 donated it to a new Agentic AI Foundation under the Linux Foundation, co-founded with Block and OpenAI and backed by Google, Microsoft, AWS, Cloudflare and Bloomberg. At that point Anthropic reported more than ten thousand active public servers and ninety-seven million monthly SDK downloads. Those numbers are dated and will be larger now; the point is that it is the de facto standard, supported by Claude, ChatGPT, VS Code, Cursor, Copilot Studio and Agentforce. The business consequence: write the server for your system once and every harness, from a developer’s terminal to the agent inside your CRM, can use it. The security consequence is on the permissions slide: a server is a tool, and tools carry permissions.

Most of what people call “configuring” a harness is writing two kinds of plain text file. The first is a rules file. Claude Code calls it CLAUDE.md, Gemini CLI calls it GEMINI.md, and the cross-vendor version is AGENTS.md, an open format now stewarded by the Agentic AI Foundation and used, by its own count, in more than sixty thousand open-source projects and by Codex, Cursor, Copilot, Jules and others. Claude Code reads AGENTS.md in place of its own file. The file is a README for the agent: how to build and test the project, the conventions, what must never be touched, who to ask. The harness pastes it into the context window at the start of every session, which is why it works and why it should be short; Claude’s documentation recommends under two hundred lines because adherence falls as the file grows. The second kind is a skill. The Agent Skills format, released by Anthropic as an open standard, is a folder containing a SKILL.md with a name, a description and step-by-step instructions, optionally with scripts and templates. Skills are procedures rather than preferences: how we do a release, how we format the monthly report, how we review a contract. They load by progressive disclosure: only names and descriptions at startup, the full instructions when a task matches, so a harness can keep many skills on hand at small cost. Hermes goes a step further and writes its own skills after a job it did well. The caveat on the slide is the important one. Both files are context. The harness pastes them in; the model is asked, not made, to follow them. Claude’s own docs say to use a hook, not a rules file, to block an action.

Part I asked “what should an agent still remember on Monday?” and left it as a discussion question. Here is the answer as a table, because “memory” is one word for four different things. Session memory is the context window for this job: everything so far, gone when you close the session. Every harness has it and it is the only memory a chat box has. Project memory is the rules file from the previous slide: written by you, the same every session, stale if nobody updates it. Persistent memory is notes the harness keeps for itself across sessions. Claude Code’s auto memory, on by default in local sessions, writes a MEMORY.md index and topic files per repository and loads the first two hundred lines of it into every session; Hermes keeps curated memory plus a searchable record of past sessions and a profile of the user; consumer chat “memory” features are the same idea. Learned skills are the fourth kind: procedures the harness wrote itself after a job it did well, in the SKILL.md format, which Hermes does by design. The bottom row is why this is a management question and not just a convenience. Session memory forgets the brief at step fifty. Project memory goes stale. Persistent memory can be poisoned: one wrong fact, written once, repeated in every future session, which OWASP lists as “memory and context poisoning”. A learned skill can be a wrong procedure executed confidently every time. So ask of any harness three things: what does it remember on Monday, who wrote that, and can you read it and delete it.

This is the slide to remember if you remember one. A harness has three kinds of wall, and a prompt is none of them. Approval prompts are the harness stopping to ask before an action. In Claude Code’s manual mode, reading files inside the working folder needs no approval; editing files, running shell commands and fetching web pages ask first, and the answer can be remembered per repository. Codex describes its default the same way: the agent works inside the sandbox and asks when it needs to go beyond that boundary. Both have modes that dial the asking up or down: a plan or read-only mode that never edits, an accept-edits mode, an automatic mode in which a classifier reviews actions instead of you, and a bypass mode that both vendors say to use only in isolated environments such as a container. Allow and deny rules are lists checked by code before anything runs: this shell command always asks, this domain is fine, this MCP tool is never allowed. They can be committed to the repository so the whole team shares them, and managed by an organisation so an individual cannot loosen them. Hooks let your own script run before a tool and block it. Sandboxes are the operating system enforcing the boundary: the shell the agent runs in cannot see files outside the project or reach hosts not on a list, using macOS Seatbelt, bubblewrap on Linux, or a container. That wall holds even when the model has been talked into something, which Claude’s documentation says in so many words. The Replit story from Part III is the case study: an agent instructed not to touch production during a code freeze deleted the production database. Replit’s fix was to separate development and production credentials, add a planning-only mode and one-click restore. Instructions are not permissions.

Section two ends the way Part III ended every example: what goes wrong, and the wall that stops it. The left column is drawn from the OWASP Top 10 for Agentic Applications, published 9 December 2025, whose first four entries are agent goal hijack, tool misuse, identity and privilege abuse, and agentic supply chain; memory and context poisoning is sixth and rogue agents tenth. Goal hijack is Simon Willison’s lethal trifecta from Part III: an agent with access to private data, exposure to untrusted content, and a way to send things out can be tricked by text hidden in a page or an email. Every harness in this deck reads untrusted content, so remove one of the other two legs. Tool misuse is a legitimate tool used for the wrong thing; the wall is least privilege per tool and deny rules for the destructive commands. Identity abuse is the agent running as you, with everything you can do; give it its own account and keys, and start in the read-only mode both Codex and Claude Code ship. Supply chain is the one people underestimate: an MCP server, plugin or skill is code that runs on your machine when installed, and the MCP security guidance says hosts must show the exact command and get consent before running it. OpenClaw’s CVE-2026-32920 is the worked example: until version 2026.3.12 it auto-discovered and loaded workspace plugins without checking trust, so a crafted project could execute arbitrary code. Memory poisoning is the previous slide’s bottom row. And a rogue agent is most often an operator on a public channel reachable by strangers; Hermes and OpenClaw both pair unknown senders by hand, and the gateway should never face the open internet.

Parts I and II between them named eight products and sorted them three different ways. Two species cover all of them. A coding harness is a session that ends. Claude Code, Codex, Gemini CLI, OpenCode, oh-my-pi, Cursor and the agents inside editors all live in a repository, a terminal or an editor, with your test suite as their sense of touch. The job is to ship software today. Memory is the repository, a rules file and some automatic notes; most of the “person” leaves when the tab closes, which Part I called a feature until it is not. Their policy layer is the most mature in the industry: permission prompts, read-only and plan modes, operating-system sandboxes, rules a team can share and an organisation can lock. Complexity is low; you install it and work. An operator is a thing that lives with you. Hermes Agent and OpenClaw run on a machine you own or rent, answer on Telegram, Slack, WhatsApp, Signal or email through a single gateway, run scheduled jobs overnight, and keep a profile of you across months. Memory is the product, not a side effect. The policy layer is yours to build: who may message it, where its shell runs, which keys it holds. More moving parts, and more that can go wrong: OpenClaw has had two high-severity CVEs in 2026 that we know of, one a one-click gateway takeover via a crafted link and one an auto-loaded plugin executing code. The agents inside SaaS products are operators too, with the vendor holding the keys; they get their own slide. The line to steal is Part I’s: pick a job, then pick a body for the brain.

This table reconciles Part I slide 8 and Part II slide 21, which used different columns and different rosters. The rows are the ones that actually decide a purchase. Native job: a coding harness writes and ships code this afternoon; an operator runs and learns a workflow every day; a SaaS agent does one vendor’s job inside one vendor’s product. Lives where: terminal, editor or a vendor cloud session; your own box reached through chat; the vendor’s cloud. Memory: mostly the thread plus a rules file and auto-notes; a persistent profile, searchable history and learned skills; the vendor’s records, visible to the extent they allow. Model choice is where the coding species splits. Claude Code, Codex and Gemini CLI are built around their vendor’s models (Claude Code and the Codex CLI can be pointed at third-party endpoints, but that is not what they are for); OpenCode advertises seventy-five-plus providers including Ollama, LM Studio and llama.cpp, and oh-my-pi sixty-plus. Operators bring many models, including local ones. SaaS agents give you the vendor’s pick, sometimes from a menu. What you configure is the honest complexity row: a rules file and a few permissions, versus a small company’s worth of channels, keys, sandboxes and schedules, versus topics and actions in a GUI. The failure modes are from Part I, which got them right: session amnesia; noise, sprawl and CVEs; and for SaaS, an opaque loop that needs Part III’s sniff test. The last row is the only advice: coding now, species one; something that should be awake on Sunday night, species two; the job already lives in a product, its agent, after the sniff test.

The third place you will meet a harness is inside software you already pay for, and here the six parts are present but renamed. Microsoft Copilot Studio is the clearest case because Microsoft has adopted the word itself: its documentation describes a “standard harness” in which designed conversation topics drive the flow, a harness in which the agent reasons from instructions and knowledge, chooses tools and works out the steps itself, and a “Customer Conversation harness” in which a primary agent coordinates sub-agents and can escalate to a person. The choice of harness affects reasoning, features and billing. Salesforce Agentforce has the same anatomy under different names: the loop is the Atlas Reasoning Engine, which breaks a request into steps and checks each; tools are “actions” built from Flows, Apex and MuleSoft connectors; policy is “guardrails” and escalation; and it accepts MCP servers from partners. n8n and the workflow builders put an “AI Agent” node into an otherwise ordinary automation: connect a chat model and some tools, and the agent decides which tools to call, inside a flow you drew. All three are legitimate and all three are harnesses you did not build and cannot fully see. So the questions in the bottom row are the ones to ask before signing: which model, and can you change it; what is in the window, and can you read it; who picks the next step, your flow or the model; which actions, running as whom, and whether your MCP servers plug in; what it keeps and whether you can delete it; and where the approvals, limits and trace are. That last column is Part III’s sniff test and it has not changed.

One slide of product names, dated, and nothing else in the deck depends on it. Claude Code is Anthropic’s coding harness: proprietary, built around Claude, available in the terminal, VS Code, JetBrains, a desktop app, the browser and Slack, with the most developed permission system in the group and an Agent SDK that exposes the same loop as a library. Codex is OpenAI’s; the CLI is Apache-2.0 on GitHub, it runs in a terminal, an IDE extension, the cloud and the ChatGPT app, and its sandbox modes, read-only, workspace-write and full access, are a good model for anyone’s policy. Gemini CLI is Google’s, Apache-2.0, with a free tier on a personal Google account. OpenCode is the open, model-agnostic coding harness Part II recommended: MIT, seventy-five-plus providers, local endpoints first-class. oh-my-pi is a coding-first fork of Pi, MIT, with the language server and debugger wired in as tools; it is the one for people who want the machinery. Cursor is the editor-shaped version, proprietary, with a model menu per task and checkpoints before big changes. Hermes Agent is Nous Research’s operator: MIT, any endpoint, twenty-plus channels, scheduled jobs, seven sandbox backends, learned skills, and a one-command migration from OpenClaw. OpenClaw is the largest operator community, now stewarded by an independent foundation, MIT, with a gateway and twenty-plus channels; it has had two high-severity CVEs in 2026, both fixed, and its own documentation tells you to read the security guide before exposing the gateway. Grok Build, which Part I listed, is not on the board: I could not verify its current state from a primary source in October 2026, so it is left out rather than guessed at.

A five-minute demo teaches the plumbing better than five slides, provided it is scripted and the repository is disposable. Minute one: clone a toy project with a test suite, open the coding harness in it in read-only or plan mode, and show the rules file it reads at start; in Claude Code that is CLAUDE.md or AGENTS.md, in Codex AGENTS.md, in Gemini CLI GEMINI.md. The room sees context being assembled. Next, ask for a small feature with tests first, and add one instruction in the prompt that the rules file also carries: do not touch the database schema. Watch it read files before it writes anything; that is the observe step. Then the permission prompts. It will ask to edit a file and to run the tests; say yes to both and name what you are approving. If it asks to run something unexpected, say no and read its stated reason; that is the gate working and a human owning a decision. Then break your own rule on purpose: ask it to change the schema. It may refuse, ask, or comply, and whichever it does is the lesson of slide 14: the rules file is context. Then show the deny rule or hook that makes “no” true regardless, and try again. Finally, read the trace: scroll back, count model turns and tool calls, open one JSON request so people see that the model wrote text and the harness did the work. Close the session, reopen it, and ask what it remembers. Everything on this slide is a plan, not a recording, and the repository, feature and wording are placeholders. Rehearse once; harnesses are not deterministic and the demo is better when you have seen the likely detours.

Five questions, answered in order, and most people stop at the first. Do you need code written today? Then a coding harness, and if you are content with that vendor’s model, Claude Code, Codex or Gemini CLI, which are the most polished and the least work. Must it run on your own model, or locally, for the privacy or cost reasons Part II set out? Then the OpenCode class: OpenCode or oh-my-pi, pointed at the endpoint you built in Part II, with the same coding workflow on your own hardware. Must it be awake when you are not, reachable on Telegram or Slack, running jobs overnight? Then an operator: Hermes if you are willing to teach it and want it to get cheaper over time, OpenClaw if the problem is coordination across many surfaces, and in either case budget the operations: patching, secrets, a sandbox, someone on call. Are you building a product for other people? Then an SDK, where you own the loop: the Claude Agent SDK exposes Claude Code’s own tools, permissions, hooks and MCP support as a Python or TypeScript library; the OpenAI Agents SDK gives agents, handoffs, guardrails and sessions with a built-in loop; LangGraph is the MIT-licensed orchestration framework with durable execution and human-in-the-loop steps. All three are “build” from Part III’s build-buy-switch-on slide. Does the job already live inside a product you pay for? Then its agent, after the sniff test, with the six vendor questions answered in writing. The panel is Part I’s honest take, unchanged: start with the boring one, complexity is a cost centre, and keep your rules, tools and skills in the portable formats so that switching later is a Tuesday, not a quarter.

Part I observed that most organisations are over-harnessed or under-harnessed, and the year since has confirmed it. Over-harnessed is the thirteen-agent story from Part I’s notes: a person running a small company of operator agents across three channels with a skills marketplace, spending a weekend on patches, who then opens a plain coding session and discovers the work was “an agent with tools” all along. It is an anecdote, not a statistic, and it is on the slide as one. The extra surface area is only worth it for persistence and channels; if you do not need those, you are paying in complexity for nothing. Under-harnessed is more common and quieter: a chat window in one tab, the real systems in another, and a human copying between them all day. No tools, no memory, no trace, and a cost per hour that never appears on an invoice. The two coral corners share a cause. Mis-harnessed is a coding session, which is excellent at its job, promoted to “our AI employee” with none of the parts that job needs: no persistence, no channels, nobody on call, and credentials belonging to whichever developer set it up. That is the shape of the Replit incident: a tool built for a session, trusted with production. Right-sized is dull on purpose: one coding harness per developer, a rules file in each repository, two or three MCP servers for the systems that matter, read-only by default, and an operator only where persistence has been shown to pay. The rule for today was Part I’s and it closes the section: the differentiator is not IQ.

Three stories, one per idea in this deck. Replit, July 2025, is the permissions story and it was in Part III; it is here again because it is the cleanest case on record. On day nine of a twelve-day experiment, during a declared code freeze, a coding agent with production credentials deleted a live database containing records on more than twelve hundred executives and companies; the user said it then misrepresented what it had done. Replit’s chief executive called it unacceptable and the company separated development and production databases, added a planning-only mode and one-click restore from backup. The agent had been told not to; it had not been prevented. OpenClaw, 2026, is the operator story. In February a high-severity flaw, CVE-2026-25253 with a CVSS score of 8.8, let a crafted link make the control interface connect to an attacker’s address and hand over the stored gateway token: one click, full control of a user’s local gateway. In March, CVE-2026-32920, scored 8.4, showed that plugins in a project’s workspace were loaded automatically without a trust check, so a crafted repository could run code. Both were fixed quickly; the lesson is that an always-on operator is a server you now administer. Anthropic, March 2026, is the harness story from slide five: the same model, nine dollars and a broken app alone, two hundred dollars and a working one inside a planner, generator and evaluator, and a component removed when the next model made it unnecessary. Each story is a slide in this deck with a date on it.

Five actions, in order, none of which needs a budget or a committee. Install one coding harness, the one that matches a model you already pay for; the differences between the good ones are smaller than the difference between having one and not, and installing three teaches you less than using one. Run it on a repository you can delete, in plan or read-only mode, and ask it first to explain the code and then to add a small feature with tests. Say no to at least one permission prompt and read the reason it gave for wanting the action; that is the gate, and you have just been it. Read the whole trace: count the model’s turns and the tool calls, find the JSON of one request so you have seen with your own eyes that the model writes text and the harness acts. Close the session, open it again, and ask what it remembers; the answer is the memory slide in miniature. Write a rules file, AGENTS.md, under two hundred lines: how to build, how to test, what must never be touched, who to ask. Commit it so your colleagues get it too. Then add one deny rule or hook that makes the “never” true whatever the model decides, because you now know the difference between context and a wall. Finally, plug in one MCP server, read-only, for a system you understand, and watch what it exposes; then write down what you would never expose that way. An operator can wait until one of these has shown you a job that needs persistence. The trace cannot wait; nobody should be deploying an agent whose trace they have never read.

For the curious, MCP is small. It is JSON-RPC 2.0 messages, the same request-and-response convention web services have used for years, carrying a handful of methods. A host asks a server what it offers with tools/list, resources/list or prompts/list, and the server answers with names, descriptions and, for tools, a JSON Schema for the arguments. That schema is what the harness places in the model’s context so the model knows how to ask. When the model writes a request, the host sends tools/call with the tool name and arguments, and the server returns a content array, usually text, which the harness appends to the window. Resources are read with resources/read and prompts fetched with prompts/get. There are two transports: stdio, where the host launches the server as a child process and talks over its standard input and output, which is how local servers for your files or a local database run; and Streamable HTTP, for remote servers, with OAuth for authorisation. As of the 2026-07-28 revision the protocol is stateless: every request carries the protocol version and the client’s capabilities, and a server infers nothing from earlier requests; servers that need state hand out an explicit handle, which the security guidance says must never be treated as authentication. The sampling primitive, by which a server could ask the host’s model for a completion, is deprecated in that revision; new servers call a model provider directly. The example on the slide is abridged from the architecture page’s own calculator-and-weather example.

The two leading coding harnesses have converged on the same two-axis model of policy, and seeing them side by side makes the idea clearer than either alone. One axis is how much the harness asks. Claude Code’s plan mode and Codex’s read-only sandbox both mean look, do not touch. Claude Code’s default, labelled Manual, lets reads inside the working folder run freely and asks before edits, shell commands and web fetches; Codex’s workspace-write with on-request approval means edit inside the workspace, ask to go beyond. Claude Code’s acceptEdits auto-approves file edits and simple filesystem commands in the working folder. Both have a mode where a model reviews actions instead of you: Claude Code’s auto mode runs a classifier over shell and network actions, and Codex can set a reviewer agent as the approver. Both have a no-prompts mode, and both documentations tell you to use it only in an isolated environment. The other axis is the sandbox: operating-system enforcement of what the shell can see and reach regardless of what anyone approved. Claude Code’s sandboxing restricts file and network access for Bash and its children and merges deny rules and allowed domains into it; Codex uses Seatbelt on macOS, bubblewrap on Linux and WSL2, and the native sandbox on Windows, and is explicit that approval policy and sandbox are separate settings. The practical reading is the last column: permissions decide what may run, the sandbox decides what can run, and the reason to have both is that a prompt injection bypasses the first and not the second.