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.

harness engineeringconfigurationcodexagents.mdsandboxingFact-checked 2026-07-06
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:

  1. Personal defaults in ~/.codex/AGENTS.md.
  2. Repo instructions in AGENTS.md and nested overrides where needed.
  3. Runtime policy in ~/.codex/config.toml and trusted project .codex/config.toml.
  4. Sandbox and approval settings for read-only, normal implementation, and unattended work.
  5. Skills and plugins for reusable procedures.
  6. MCP and app integrations for repeated external context.
  7. 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.

MechanismUse it forAvoid it when
PromptOne current request, constraints, and evidenceThe instruction should persist across runs
~/.codex/AGENTS.mdPersonal working agreements and response preferencesThe rule belongs to a team or repo
Repo AGENTS.mdSetup, checks, protected paths, review rules, definitions of doneIt is a long reusable workflow
AGENTS.override.mdReplacing parent instructions for a nested areaA normal additive nested AGENTS.md is enough
config.tomlSandbox, approvals, MCP, model, project doc loading, profilesThe content is documentation, not runtime behavior
SkillA repeated workflow with references, scripts, or templatesThe repo needs one stable fact loaded every run
PluginDistribution of skills, apps, MCP, or hooks across usersThe workflow is still personal or experimental
MCPExternal systems or data queried repeatedlyA one-off export or pasted link is sufficient
SubagentParallel exploration, implementation worker, or fresh reviewThe task is small and the parent context should handle it
EvalMeasuring whether the harness improved outcomesYou only need one manual check for one task
Codex configuration mechanisms. Put each rule where Codex can use it with the least ambiguity.

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.

Switch to Codex mode, score the setup, route repeated problems to the right mechanism, scan AGENTS.md text, and generate a starter manifest.

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.

Minimal Codex harness layout
bash
~/.codex/
|-- AGENTS.md
`-- config.toml
 
repo/
|-- AGENTS.md
|-- .codex/
|   `-- config.toml
|-- .agents/
|   `-- skills/
|       `-- release-check/
|           `-- SKILL.md
|-- docs/
|   `-- agent-runs/
`-- package.json
~/.codex/AGENTS.md
markdown
# 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.
Repo-level AGENTS.md
markdown
# 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.
Nested AGENTS.override.md use case
markdown
# 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.
~/.codex/config.toml
toml
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
Trusted project .codex/config.toml
toml
# .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 = false

Separate 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.

PostureUse it forConfig or launch shape
Read-only investigationUnderstanding a repo, reviewing a diff, answering questionssandbox_mode = "read-only" with approvals left on or disabled for non-interactive review
Planned implementationNormal local coding after a plan is acceptedsandbox_mode = "workspace-write" and approval_policy = "on-request"
Unattended validationCI or isolated automation with no human to answer promptsworkspace-write plus approval_policy = "never" only in a controlled runner
Full accessRare disposable environments where broad access is intendeddanger-full-access; avoid on a developer laptop
Permission postures for common Codex work.
Read-only investigation prompt
markdown
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-mode task pattern
markdown
/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.

.agents/skills/release-check/SKILL.md
markdown
---
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.
NeedUse MCP?Codex mechanism
Read docs onceNoPaste the URL or use web/search context
Query the same docs server every weekYes[mcp_servers.docs] in user or trusted project config
Use GitHub, Slack, Gmail, or Drive workflowsMaybeInstall an official plugin when available; use MCP for custom systems
Expose Codex to another agentYescodex mcp-server with codex and codex-reply tools
Run a repo-local scriptNoDocument the script in AGENTS.md and allow it through sandbox/approval policy
Access sensitive production dataOnly with owner reviewPrefer read-only, audited, scoped server access
MCP configuration decision table for Codex. Start with the smallest repeatable integration.

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:

  1. Choose three representative tasks: one read-only question, one small implementation, one review task.
  2. Record the expected output, checks, or findings.
  3. Run Codex with the current harness.
  4. Save transcript links, commands, diff, and validation output.
  5. Change one harness layer.
  6. Rerun the same tasks.
  7. Keep the change only if the evidence improves or the failure mode is removed.
Weak ruleCorrected 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.
Examples of weak Codex harness rules and corrected versions.
Failure modeWhat it looks likeFix
Hidden environment driftCloud, app worktree, and local shell install different dependenciesDocument setup scripts and keep worktree setup tested
Missing setup scriptsCodex cannot reproduce a failure in a new worktreeAdd setup commands and expected services to AGENTS.md or local environments
Over-broad autonomyUnattended tasks can edit risky pathsSeparate read-only, workspace-write, and unattended profiles
Vague done criteriaGoal completes after a narrative summaryTie done to checks, artifacts, review findings, or benchmarks
Oversized AGENTS.mdInstructions crowd out task contextMove procedures into skills and keep AGENTS.md as a router
Config in docsSandbox or MCP expectations appear only in prosePut runtime settings in config.toml
Docs in configLong explanations stuffed into TOML commentsMove explanation to AGENTS.md or docs
No validation commandCodex cannot prove the changeAdd exact commands and expected result
Network assumptionsTask needs package install or docs access but network is disabledMake network need explicit and scoped
Codex harness failure modes.

Verification workflow before trusting Codex output

  1. 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.

  2. Check changed files

    Inspect git diff --stat and the actual diff. Verify that protected paths were not touched unexpectedly.

  3. Run deterministic checks

    Run install if needed, lint, typecheck, tests, build, and any repo-specific smoke test.

  4. Review artifacts

    Inspect generated reports, screenshots, previews, logs, or benchmark output. Do not rely only on a text summary.

  5. 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

  1. Create personal defaults

    Write ~/.codex/AGENTS.md for your response preferences and review style.

  2. Add repo AGENTS.md

    Document setup, checks, protected paths, and definition of done.

  3. Set conservative config

    Use workspace-write and on-request as the local default. Keep network off unless a task needs it.

  4. Practice read-only investigations

    Run codebase explanations, debugging investigations, and reviews before granting write access.

  5. Extract one skill

    Turn the most repeated prompt into a skill under .agents/skills/.

  6. Add one Goal pattern

    Use /goal only when the task has measurable evidence and a blocked stop condition.

  7. 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.