Key takeaways
- A Codex harness includes the task environment and feedback around the agent's code changes.
- The open-source Codex harness and model access are separate.
- Our proposed parser audit records changed files, test findings, and remaining work.
Take a small parser fix as a working example: a request says an empty field at the end of a CSV row is being dropped. The question is what the task gives Codex to read, what it permits Codex to change, what a person will inspect, and what remains legible if the work stops. Those choices form a practical harness engineering Codex workflow. The parser, request, and checks below are illustrative design choices.
First thoughts: harness engineering Codex work starts with the environment
Giving an agent a coding request is easy. Giving it a useful environment takes more thought. In OpenAI's internal Codex-built product experiment, engineering work included designing environments, specifying intent, and building feedback loops for agent work. Early progress in that experiment was slower because the environment was underspecified. That finding is narrow, but it points to a question every coding task can expose: what information and controls must surround the request before the resulting change can be judged?
For the hypothetical parser fix, the prompt can say what appears wrong. It does not, by itself, settle which repository instructions apply, where the parser lives, which actions are allowed, or how to inspect the result. We can specify those decisions as part of the task design, then compare what Codex returns with what we asked for.
The distinction resembles Simon Willison's account of vibe engineering: experienced professionals can use LLMs to accelerate software work while remaining accountable for the software they produce. He contrasts that posture with vibe coding, which he describes as entirely prompt-driven work that pays no attention to how the code works. A harness gives that accountability specific places to live: the task context, action boundary, inspection, and handoff.
Give the coding task a small, stable context entry point
For our example, the starting request could identify the repository instructions and the parser file that appears relevant. Those are proposed entry points for this task, not a claim about any particular repository. The agent can begin there, then follow references to other material when the task calls for it. Progressive disclosure uses a small, stable entry point and directs an agent to further context as needed.
There is also configuration outside the task text. Codex CLI defaults come from ~/.codex/config.toml; a command-line -c key=value override takes precedence for that invocation. If a parser task depends on a particular setting, name the setting as part of the proposed run. That is more concrete than assuming the prompt alone describes the environment. The task request can then stay focused on the desired parser behavior and the files that matter.
Context should give Codex a place to start, not pretend that the first file is the whole codebase. For this example, the useful question is whether the instructions and parser file lead to enough information to propose a change that a person can inspect.
Audit one parser fix from request to handoff
Imagine a parser that drops an empty trailing CSV field. The requested change is to preserve that field. Every action in this hypothetical worksheet is a proposed choice.
| Harness decision | Proposed answer for the parser fix |
|---|---|
| Context | Start with the repository instructions and the relevant parser file. Keep the requested behavior explicit: an empty final field in a CSV row should remain present. |
| Authority | Permit inspection of the relevant files and editing of the parser and a focused test. Ask before any action outside that agreed boundary. |
| Inspection | Request a focused test for the trailing empty field and inspect the resulting diff against the requested behavior. Record what the test actually reports. |
| Handoff | Return the changed-file list, test findings, and any remaining work in a short task record. Distinguish completed edits from proposed follow-up. |
The worksheet is a way to make decisions visible before the task runs. Its inspection row uses a simple feedback-control comparison: compare an observed variable with a desired value, then use the difference to guide control. Here the desired value is the requested parser behavior; the observed material would be the diff and test result. Calling this a cybernetics comparison is useful. It does not make harness engineering an established named branch of cybernetics.
The four decisions also match the kinds of controls a host application can set around an agent: execution location, accessible files and tools, approval points, observation, and the return of results to a system of record. A single parser task makes those controls easier to inspect than an abstract call for more automation.
Codex subagent guidance identifies read-heavy exploration, tests, triage, and summarization as suitable parallel work. Parallel code editing can create conflicts and coordination overhead. That makes exploring the parser and its tests a possible delegated part of this proposed audit, while the edit stays with the parent task.
Which actions can Codex take before asking?
For the parser fix, decide where Codex may write before giving it the edit. Codex sandbox mode controls where model-generated commands can write and whether they can reach the network. Approval policy controls when Codex must ask before an action, including actions that leave the sandbox or use the network. The sandbox describes available capability; the approval policy describes when a request for permission is required.
Suppose the intended task is to read repository instructions, edit the parser and its focused test, and return a diff for inspection. Those are task-design choices. If the work calls for another kind of action, the permission decision belongs at that boundary. Writing "be careful" in the prompt does not specify the same boundary as a sandbox and an approval policy.
Network authority also needs the right surface in mind. The local command network proxy filters processes inside the local command sandbox. Web search, connectors, MCP connections, browser activity, and cloud tasks use separate controls. A rule for local command traffic therefore does not describe all ways an agent might reach outside the repository. For a small parser fix, name the actual tools involved in the proposed run, then review the controls that apply to each one. This keeps the authority question attached to the work Codex is being asked to perform.
How should a Codex subagent receive the task?
A subagent is useful when the work can be divided clearly. For the parser example, the natural split is exploration: have a subagent identify relevant files and current test coverage while the parent retains the edit decision.
An illustrative delegation request would say: "Inspect the parser and relevant tests for the trailing-empty-field case. Return the files you examined, a proposed change, and any test findings. Do not edit files. Wait for your findings before the parent changes code." This is an authored request and return format, not a native Codex result format. It makes the work division, wait condition, and expected output explicit, as the documented task guidance calls for.
Delegation does not create a new permission boundary. Codex subagents inherit the parent turn's sandbox and approval settings; a custom agent file cannot replace them. If a non-interactive flow cannot surface a fresh approval, an action that needs new approval fails and returns an error to the parent workflow. That matters when a proposed exploration unexpectedly needs access beyond the original task. The parent can use the returned findings to decide what to inspect or authorize, rather than treating the subagent's request as permission already granted.
Leave work the next session can understand
The parser task may stop after exploration, after an edit, or after an inspection that finds more work. A useful handoff names which state it reached. For this illustrative task, the record could contain the requested behavior, files examined or changed, test findings as actually observed, and the next unresolved question. A future session should not have to infer completion from an unfinished diff.
There is a documented precedent in a different toolchain. In Anthropic's long-running Claude Agent SDK workflow, an initializer prepares the first-run environment and a coding agent makes incremental progress while leaving artifacts for later sessions. In that experiment, trying too much at once could exhaust context and leave a feature half implemented and undocumented. After the initial setup, asking the coding agent to work on one feature at a time addressed that tendency. That initializer pattern belongs to the Claude Agent SDK workflow; it is not a Codex feature we are claiming here.
Codex has a separate, concrete way to branch local work: codex fork <SESSION_ID> --worktree forks an explicit session into a managed Git worktree. It requires local execution and a session ID. The --last option and session picker are unsupported for that command. A worktree gives the fork a place to work; the task record still needs to say what has actually been done. A session command alone does not establish that an interrupted application's state has been restored.
Choose the Codex interface for the surrounding workflow
The parser fix does not require an integration merely because it uses an agent. The right interface depends on how the surrounding application needs to start work, observe it, and receive results. The documented integration choices include codex exec, the Codex SDK, and Codex app-server, each with a different role.
codex exec supports scripted or CI-style Codex runs that finish without human interaction. That shape fits a task whose request and return can be handled as a bounded run. If the proposed parser workflow requires a person to inspect a diff or respond to an approval, the script needs an explicit place for that decision; the fact that execution is non-interactive does not make the decision disappear.
The Codex SDK offers a programmatic interface when application code needs to start, resume, or stream Codex tasks. Codex app-server connects an application to a local Codex process. It can keep conversations open, stream events, interrupt work, expose tools, and respond to approval requests. Those are relevant when the host application itself must manage an ongoing interaction. For the parser example, the decision is whether a finished run is enough, whether application code needs task control, or whether a connected local process must handle events and approvals.
More integration surface is useful only when the task's control and observation needs call for it.
What can you inspect on GitHub?
The open-source Codex layer lives at github.com/openai/codex. Codex approval documentation also points to configuration material in that official repository. GitHub is a concrete place to inspect Codex configuration when a proposed harness depends on how the tool is set up.
The open-source layer provides a harness and integration surface. Model access and managed services are separate. So cloning or reading the repository answers a different question from choosing a subscription or estimating how much a coding task will use. The repository can inform an integration design; it is not a promise that the model service comes with the source code.
For this article's parser example, the useful GitHub question is which Codex configuration or integration behavior the proposed workflow relies on. The parser's own files and tests remain in the task's repository, wherever that task is hosted.
Is Codex free for a small harness experiment?
Codex pricing lists Free at $0 per month for quick coding tasks, with GPT-6 Luna at Standard speed in the desktop app, subject to rollout. It lists Plus at $20 per month with access on the web, in the CLI, in the IDE extension, and on iOS. Those are the named access surfaces in the plan descriptions. The Free listing does not establish CLI access, so a plan to use codex exec should not be built on that assumption.
A small parser task can still be a useful design exercise on paper: write the request, context entry point, permitted files, inspection, and handoff before deciding which interface to run. If the intended experiment specifically needs CLI commands or an application integration, the listed Plus surfaces answer a different access question than the Free desktop-app listing. The pricing page is the right place to check the current plan details when making that choice.
The $0 plan price describes access, not a fixed number of parser tasks. Usage depends on the work the agent is asked to do, which is why the size and shape of the proposed run matter alongside the plan label.
Task size changes the usage calculation
Codex message allowance depends on model choice, task size and complexity, and whether work runs locally or in the cloud. OpenAI's usage guidance says a small script or routine function may use a fraction of an allowance, while a larger project, long-running task, or extended context-heavy session uses more per message. The hypothetical parser fix may be a small request, but its actual use would depend on the model, the work it uncovers, and how it is run.
API token prices are separate from Codex subscription usage and do not estimate included tasks. A model token price cannot tell you how many Codex sessions a subscription includes.
Start with the parser task you actually need to delegate. Write its context, authority boundary, inspection request, and handoff record, then explore our harness engineering framework for a broader way to apply those decisions.