3.9 KiB
Codex Implementation Flow
Project configuration
The project configuration is .codex/config.toml. It selects GPT-6-Sol with
medium reasoning for the primary coordinator and GPT-6-Luna with high reasoning
as the default for spawned agents. Custom project agents are discovered from
.codex/agents/:
| Agent | File | Responsibility |
|---|---|---|
implementer |
.codex/agents/implementer.toml |
Implement a bounded task and focused tests |
reviewer |
.codex/agents/reviewer.toml |
Independently review actual changes without editing |
repairer |
.codex/agents/repairer.toml |
Resolve findings and provide regression evidence |
explorer |
.codex/agents/explorer.toml |
Optional read-only prerequisite research |
All four custom agents explicitly select GPT-6-Luna/high. There is no separate coordinator subagent: the primary session is the coordinator. At most three spawned threads run concurrently, but file ownership defaults to one writer.
Starting work
Open a fresh Codex session in this project, using a client that supports the documented project configuration and custom agents. Project trust, managed requirements, and explicit client/session overrides can affect which settings are applied. Verify the coordinator and spawned-agent model/effort settings in the client before implementation; report unavailable models rather than silently substituting alternatives. Existing sessions are not reconfigured by these files.
An example execution request is:
Execute the next pending milestone in PLANS.md. Use implementer for bounded implementation, a fresh reviewer for independent review, and repairer for findings. Repeat review and repair until the acceptance gates pass, update PLANS.md with evidence, and stop after accepting this milestone or recording a concrete blocker. Use explorer only when prerequisite research is needed.
For an explicitly authorized full-plan run, continue to the next milestone only after the current one is accepted. Do not confuse this project's Commit action with permission to create Git commits.
Flow and limitations
The root instructions define prepare, implement, review, repair, re-review, and
acceptance. PLANS.md is the durable record of milestone/task IDs, ownership,
progress, findings, validation, and blockers. Follow execution record rules: update current state in place, keep detailed investigations in docs/diagnostics/, detailed evidence in docs/evidence/, and superseded history in docs/history/. Include these boundaries in worker dispatches; reassess repeated failed repairs before another expensive run. The TOML files configure model
selection and agent instructions; they do not implement a deterministic workflow
engine or automatically start execution.
Reviewer/explorer read-only behavior is an instruction boundary, not a distinct OS sandbox. Custom agents inherit the parent's permission controls. This setup does not change sandbox, approvals, provider, MCP access, or user-level trust.
Container tests require a disposable Alpine Testcontainers environment, and real systemd validation requires a separate disposable VM; see TESTING.md. No role is authorized to experiment on production.
Verification status
The files were parsed as TOML and checked for consistent role names and requested
model/effort values. A live model session and subagent dispatch were not started.
The installed CLI reports version 0.161.0. Its features command does not support
--strict-config, so that command cannot establish complete schema validation.
Official references: