# Inside the open source Codex harness, and what sits outside it > The Codex harness is OpenAI’s open-source agent loop: it manages conversation state, streams execution, uses tools, enforces a sandbox and approval policy, and carries work across turns. Its policy file and session record stay with whoever runs the process. Kortix, the open-source AI Operating System, keeps that layer in a git repo. URL: https://agentharnessguide.com/codex-harness _Two files_ ## Two files, two owners The Codex harness reads its rules from a file on the machine that runs it; a Kortix project reads them from the repo. ### Codex harness `~/.codex/config.toml` ``` # Approval & Sandbox approval_policy = "on-request" # approvals_reviewer = "user" sandbox_mode = "read-only" ``` Source: https://developers.openai.com/codex/config-sample ### Kortix project `kortix.yaml` ```yaml # agents/.md one file per agent (`agents..file`) # skills//SKILL.md skills, loaded by every harness # memory/ the project brain (the `kortix-memory` skill) # tools/.ts project tools, loaded by every harness (`tools:` below) # harnesses/pi/ files only pi reads (`pi.config_dir`); create it when needed kortix_version: 2 ``` Source: https://github.com/kortix-ai/suna/blob/dev/packages/starter/templates/base/kortix.yaml ## The harness is the loop OpenAI ships with Codex The Codex harness is the agent loop behind every Codex surface. OpenAI says so directly: "The open-source Codex harness is what powers all these experiences" ([Codex as a platform](https://developers.openai.com/blog/codex-as-a-platform)). The app, the command-line interface, the IDE extension and third-party clients all sit on that one system. Microsoft's agent framework documentation gives the general definition. An agent harness is "the runtime scaffolding that turns a language model into an agent that can perform work" ([Microsoft Learn](https://learn.microsoft.com/en-us/agent-framework/concepts/harness)). For Codex, that scaffolding manages conversation state, streams execution, uses tools, enforces the sandbox and approval policies a person configures, and carries work across turns. The repository is public, and its latest release tag was `rust-v0.164.0`, published on 23 October 2026 ([openai/codex](https://github.com/openai/codex)). Reading the loop tells you what it will do before your product depends on it. ## Why the loop moves the score A harness is more than a wrapper around a model call. It decides what the model sees, when context is compacted, which tools it can reach, and who has to approve a write. Those decisions change results on the same weights. OpenAI measured the gap. On ARC-AGI-3, retained reasoning and context compaction took one of its models from 13.3% to 38.3% while cutting output tokens sixfold (checked October 2026, [OpenAI](https://developers.openai.com/blog/codex-as-a-platform)). Compaction and retained reasoning are harness behaviour, not model upgrades. A team that swaps models keeps the loop it already has; a team that keeps the model and rewrites the loop gets a different agent. That is the argument for an inspectable harness. You can point at the code that produced the number above, then change the part your workflow depends on, whether that is context management, a tool surface, or the point where a person is asked. ## Where the approval rule is written Codex reads its rules from a configuration file on the machine that runs it: `~/.codex/config.toml`, or a project-scoped `.codex/config.toml` when the settings should travel with a checkout ([sample configuration](https://developers.openai.com/codex/config-sample)). Three keys carry most of that weight. `approval_policy = "on-request"` lets the model decide when to ask. The alternatives are never prompting, or a granular policy that allows and blocks selected prompt categories. `approvals_reviewer` defaults to `user`, which puts a person at the other end of the prompt; `auto_review` hands that job to an automatic reviewer. `sandbox_mode` starts at `read-only`, with `workspace-write` and a full-access mode beside it. Inside `[sandbox_workspace_write]` the `network_access` switch stays off until someone turns it on. The loop does not have the last word on approvals. `codex app-server` exposes threads, turns and events over a documented protocol, and hands approval requests to the host application, which decides how they are answered ([OpenAI](https://developers.openai.com/blog/codex-as-a-platform)). Whoever ships the application owns the policy. In the stock command-line tool, that owner is the person at the keyboard. ## Where the session record is kept Conversation state stays local as well. The sample configuration keeps history with `[history] persistence = "save-all"`, and an optional `sqlite_home` names the directory that holds SQLite-backed runtime state ([sample configuration](https://developers.openai.com/codex/config-sample)). One developer on one machine loses nothing by that arrangement. A team does: the evidence of what an agent read, changed and shipped is spread across laptops and build machines, in a format each person controls. Reconstructing one change means asking people, not querying a store. ## What a team still has to own Once several people run agents over shared work, four things need a named owner: the configuration an agent runs from, the rule for what it may do without asking, the record of what it did, and the route its output takes to the main branch. None of the four is a feature of the loop. Kortix keeps them in git. Your agents, the skills they share, your company memory, and every connector live in one git repo ([Kortix on GitHub](https://github.com/kortix-ai/suna)). The manifest is governance only. One `agents:` map per project carries connectors, secrets, permissions, skills and workspace, plus the path to each agent's `.md` ([kortix.yaml](https://github.com/kortix-ai/suna/blob/dev/packages/starter/templates/base/kortix.yaml)). A permission change becomes a diff someone reviews instead of a setting on one laptop. The rest is two rules and a route. Approval gates you set. Off until you set them. One isolated sandbox per session, each session with its own isolated machine and branch. Session work reaches `main` through a change request, and merge is default-deny for agents. The branch that proves the work is also the branch a person reads. A Kortix project does not run the Codex harness. What differs for a team is where the rules live: one configuration sits in a home directory, the other in a repo the whole company can read and diff. ## Which shape fits your work - **One developer, local work.** Run the Codex command-line tool or the Codex SDK and keep `~/.codex/config.toml` to yourself. The approval prompt and the session record on your own machine are enough, and the harness is there to read when a default surprises you. - **A product that embeds an agent.** Use `codex app-server` and let the product own the approval flow, its records and its interface, with the loop underneath. Codex as a platform frames exactly this split, and the approval route is the part to design first. - **A team working in one repo.** Permissions have to be reviewable and the history has to be shared. Either write that layer around the harness, or run the agents somewhere config, permissions and history already live in the repository. The [agent harness comparison](/agent-harness-comparison) sets the shapes side by side. Before you pick a shape, answer who approves a write, where that rule is stored, and who can read the record afterwards. The model the loop calls comes second. _Questions_ ## Questions about the Codex harness ### Is the Codex harness open source? Yes. OpenAI publishes the harness, the command-line tool, app-server and the official Codex SDK in the openai/codex repository, so the layer between an application and the model can be read and adapted rather than guessed at. Model access and OpenAI’s managed services sit outside that open-source layer. ### Can I use the Codex harness with a model other than OpenAI? Yes, through the model provider table in `config.toml`. The sample configuration ships built-in providers for Ollama, LM Studio and Amazon Bedrock, and a custom provider entry can point at another endpoint. OpenAI keeps model access separate from the open-source harness, so the loop and the model are two decisions. ### What does the Codex harness not include? It does not include the model, or a shared home for a team’s configuration, approval record and session history. Those stay with whoever runs the process, which is why teams wrap the loop in an application, or run it where config and history live in a repo. ## Put the rules where the team can read them. Kortix keeps agents, skills, memory and connectors in one git repo, with approval gates you set and a change request a person approves. [Try Kortix](https://kortix.com) · [Open source harnesses](https://agentharnessguide.com/open-source-agent-harness)