The Forge · 18 min mission
Codex Harness Engineering and Configuration
Build a repeatable Codex harness with AGENTS.md, config.toml, skills, MCP, approvals, sandboxing, goals, and validation.
On this page
This guide shows you how to build a Codex harness with AGENTS.md, config.toml, skills, MCP, subagents, sandboxing, Goal mode, read-only investigation patterns, and validation loops.
Who this is for
Use this if you work with Codex in the CLI, IDE extension, desktop app, or cloud and want the same repository to produce repeatable results across sessions. The harness is the operating layer around Codex: instructions, setup scripts, permissions, reusable workflows, external tools, review gates, and evidence.
You need:
- Codex installed or available through the app, IDE extension, or cloud.
- Permission to add
AGENTS.md,.codex/config.toml,.agents/skills/, or.codex/agents/. - A validation surface: tests, lint, typecheck, build, preview, benchmark, report, or review rubric.
- A clear trust boundary for the repo before project config is loaded.
Expected result: a Codex setup that can investigate safely, implement inside a known sandbox, verify its work, and stop with evidence instead of a vague completion summary.
Define harness engineering in Codex
Codex already runs an agent loop: it reads the prompt, inspects the workspace, chooses tool actions, applies edits when allowed, reads the results, and continues until it returns an answer or completes the task. Harness engineering is how you shape that loop for one repo and one team.
A Codex harness has seven parts:
- Personal defaults in
~/.codex/AGENTS.md. - Repo instructions in
AGENTS.mdand nested overrides where needed. - Runtime policy in
~/.codex/config.tomland trusted project.codex/config.toml. - Sandbox and approval settings for read-only, normal implementation, and unattended work.
- Skills and plugins for reusable procedures.
- MCP and app integrations for repeated external context.
- Validation loops using
/plan,/goal,/review, tests, builds, previews, and cloud/app worktrees.
Treat each part as a control surface. If the rule should be enforced by a sandbox or permission setting, do not hide it in prose.
| Mechanism | Use it for | Avoid it when |
|---|---|---|
| Prompt | One current request, constraints, and evidence | The instruction should persist across runs |
~/.codex/AGENTS.md | Personal working agreements and response preferences | The rule belongs to a team or repo |
Repo AGENTS.md | Setup, checks, protected paths, review rules, definitions of done | It is a long reusable workflow |
AGENTS.override.md | Replacing parent instructions for a nested area | A normal additive nested AGENTS.md is enough |
config.toml | Sandbox, approvals, MCP, model, project doc loading, profiles | The content is documentation, not runtime behavior |
| Skill | A repeated workflow with references, scripts, or templates | The repo needs one stable fact loaded every run |
| Plugin | Distribution of skills, apps, MCP, or hooks across users | The workflow is still personal or experimental |
| MCP | External systems or data queried repeatedly | A one-off export or pasted link is sufficient |
| Subagent | Parallel exploration, implementation worker, or fresh review | The task is small and the parent context should handle it |
| Eval | Measuring whether the harness improved outcomes | You only need one manual check for one task |
Audit and generate a Codex harness starter
Harness workbench
Check the setup before the agent runs
Use this locally before you widen permissions, add MCP, or start a long run.
Start with the minimal setup
The minimal Codex setup has two instruction files and one config file. Keep personal habits out of the repo. Keep repo policy out of your home directory.
~/.codex/
|-- AGENTS.md
`-- config.toml
repo/
|-- AGENTS.md
|-- .codex/
| `-- config.toml
|-- .agents/
| `-- skills/
| `-- release-check/
| `-- SKILL.md
|-- docs/
| `-- agent-runs/
`-- package.json# Personal Codex instructions
## Working agreements
- Be concise unless the task asks for detailed reasoning.
- Prefer small, reviewable diffs.
- Before editing, identify the validation command you will run.
- Ask before adding a production dependency.
- Do not commit unless I explicitly ask.
## Review style
- Lead with correctness, security, data loss, and regression risk.
- Include file paths and evidence for each finding.
- Do not list broad style preferences as blockers.# AGENTS.md
## Project map
- App routes: app/
- Shared code: lib/
- UI components: components/
- Generated output: out/ and .next/ must not be edited.
## Setup
- Install: npm install
- Dev server: npm run dev
## Checks
- Lint: npm run lint
- Tests: npm test
- Build: npm run build
## Protected areas
- Do not change auth, payments, secrets, migrations, deploy scripts, or generated files without explicit approval.
- Do not weaken tests or lint rules to make a task pass.
## Definition of done
- The requested behavior is implemented.
- Relevant tests or checks pass.
- The final response lists changed files, commands run, and remaining risk.
## Review guidelines
- P0: data loss, auth bypass, secret exposure, destructive migration, payment risk.
- P1: production regression, broken critical path, missing test for changed behavior.
- P2: maintainability or coverage risk that should be fixed before merge.
- P3: small cleanup or wording issue.# packages/legacy-billing/AGENTS.override.md
## Override for legacy billing
This package does not follow the root TypeScript conventions.
- Do not run the root formatter here.
- Use: npm run test:legacy-billing
- Do not change database schema files in this package.
- Any behavior change needs an owner approval note in docs/agent-runs/.
This file replaces parent instructions for this subtree because the normal root checks are wrong for this package.model = "gpt-5.5"
sandbox_mode = "workspace-write"
approval_policy = "on-request"
project_doc_max_bytes = 32768
project_doc_fallback_filenames = ["AGENTS.local.md"]
[sandbox_workspace_write]
network_access = false
[features]
goals = true
[mcp_servers.docs]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
startup_timeout_sec = 20# .codex/config.toml
# Keep this repo-scoped. Provider, auth, telemetry, and profile-selection keys belong in user config.
sandbox_mode = "workspace-write"
approval_policy = "on-request"
project_doc_max_bytes = 20000
project_doc_fallback_filenames = ["AGENTS.local.md"]
[sandbox_workspace_write]
network_access = falseSeparate investigation, implementation, and unattended profiles
Many teams say "Ask mode" to mean a read-only investigation pass. The current OpenAI docs describe Goal mode and plan/read-only/chat patterns, not a formal Codex mode with that exact name. The useful harness pattern is still clear: investigate with read-only permissions, plan before edits, then switch to workspace-write only when the plan is accepted.
| Posture | Use it for | Config or launch shape |
|---|---|---|
| Read-only investigation | Understanding a repo, reviewing a diff, answering questions | sandbox_mode = "read-only" with approvals left on or disabled for non-interactive review |
| Planned implementation | Normal local coding after a plan is accepted | sandbox_mode = "workspace-write" and approval_policy = "on-request" |
| Unattended validation | CI or isolated automation with no human to answer prompts | workspace-write plus approval_policy = "never" only in a controlled runner |
| Full access | Rare disposable environments where broad access is intended | danger-full-access; avoid on a developer laptop |
Run in read-only mode.
Task:
Explain why the checkout tests are flaky.
Boundaries:
- Do not edit files.
- Do not install dependencies.
- Read only test files, CI logs, package scripts, and related checkout code.
Return:
- most likely cause
- evidence with file paths or log lines
- the smallest implementation plan
- the exact commands to run after the fix/goal Reduce p95 checkout latency below 120 ms, verified by the checkout benchmark, while keeping the correctness suite green. Use only checkout service code, benchmark fixtures, and related tests. Between iterations, record what changed, what the benchmark showed, and the next experiment. If the benchmark cannot run or no valid path remains, stop with evidence, attempted paths, blocker, and next input needed.Package repeated work as a Codex skill
Use a skill when the workflow has steps, references, scripts, or templates that should load only when the task needs them. Keep repo rules in AGENTS.md; keep the reusable method in the skill.
---
name: release-check
description: Use before merging or publishing a change that needs lint, tests, build, preview review, and a risk note.
---
# Release check
## Inputs
- current diff
- repo AGENTS.md
- validation commands
- preview route when UI changed
## Procedure
1. Inspect the current diff.
2. Run the relevant lint, test, and build commands.
3. Review the runtime behavior when UI or API behavior changed.
4. Run /review or request a fresh reviewer for non-trivial diffs.
5. Return changed files, commands run, failures, fixes, and remaining risk.
## Stop conditions
- Validation passes and no P0/P1 review finding remains.
- A required secret, owner approval, or external service is missing.| Need | Use MCP? | Codex mechanism |
|---|---|---|
| Read docs once | No | Paste the URL or use web/search context |
| Query the same docs server every week | Yes | [mcp_servers.docs] in user or trusted project config |
| Use GitHub, Slack, Gmail, or Drive workflows | Maybe | Install an official plugin when available; use MCP for custom systems |
| Expose Codex to another agent | Yes | codex mcp-server with codex and codex-reply tools |
| Run a repo-local script | No | Document the script in AGENTS.md and allow it through sandbox/approval policy |
| Access sensitive production data | Only with owner review | Prefer read-only, audited, scoped server access |
Add evals when the harness changes
An eval does not need to be a large benchmark. Start with a small fixture set that catches the failure you care about. When you change AGENTS.md, config, a skill, a plugin, or an MCP server, rerun the fixture and compare the evidence.
A simple eval loop:
- Choose three representative tasks: one read-only question, one small implementation, one review task.
- Record the expected output, checks, or findings.
- Run Codex with the current harness.
- Save transcript links, commands, diff, and validation output.
- Change one harness layer.
- Rerun the same tasks.
- Keep the change only if the evidence improves or the failure mode is removed.
| Weak rule | Corrected rule |
|---|---|
Write production-ready code. | Before completion, run npm run lint, npm test, and npm run build; list any failure with command output. |
Use full access so you are not blocked. | Use workspace-write with on-request locally; reserve danger-full-access for disposable isolated runners. |
Ask if unsure. | If the task touches auth, payments, secrets, migrations, or deployment scripts, stop and ask for owner approval before editing. |
Review your output. | Run /review on the diff or spawn a read-only reviewer subagent; require no P0/P1 findings before completion. |
| Failure mode | What it looks like | Fix |
|---|---|---|
| Hidden environment drift | Cloud, app worktree, and local shell install different dependencies | Document setup scripts and keep worktree setup tested |
| Missing setup scripts | Codex cannot reproduce a failure in a new worktree | Add setup commands and expected services to AGENTS.md or local environments |
| Over-broad autonomy | Unattended tasks can edit risky paths | Separate read-only, workspace-write, and unattended profiles |
| Vague done criteria | Goal completes after a narrative summary | Tie done to checks, artifacts, review findings, or benchmarks |
| Oversized AGENTS.md | Instructions crowd out task context | Move procedures into skills and keep AGENTS.md as a router |
| Config in docs | Sandbox or MCP expectations appear only in prose | Put runtime settings in config.toml |
| Docs in config | Long explanations stuffed into TOML comments | Move explanation to AGENTS.md or docs |
| No validation command | Codex cannot prove the change | Add exact commands and expected result |
| Network assumptions | Task needs package install or docs access but network is disabled | Make network need explicit and scoped |
Verification workflow before trusting Codex output
Inspect the route of work
Confirm whether the task ran locally, in a worktree, in the IDE, or in cloud. The validation evidence should match that environment.
Check changed files
Inspect
git diff --statand the actual diff. Verify that protected paths were not touched unexpectedly.Run deterministic checks
Run install if needed, lint, typecheck, tests, build, and any repo-specific smoke test.
Review artifacts
Inspect generated reports, screenshots, previews, logs, or benchmark output. Do not rely only on a text summary.
Run review
Use
/review, a reviewer subagent, or human review for non-trivial diffs. Record any P0/P1 finding before merge.
Adopt the Codex harness incrementally
Create personal defaults
Write
~/.codex/AGENTS.mdfor your response preferences and review style.Add repo AGENTS.md
Document setup, checks, protected paths, and definition of done.
Set conservative config
Use workspace-write and on-request as the local default. Keep network off unless a task needs it.
Practice read-only investigations
Run codebase explanations, debugging investigations, and reviews before granting write access.
Extract one skill
Turn the most repeated prompt into a skill under
.agents/skills/.Add one Goal pattern
Use
/goalonly when the task has measurable evidence and a blocked stop condition.Add MCP or plugin last
Connect one repeated external workflow. Audit its permissions before adding more.
Reach the end and this star joins your charted sky.