Codex harness
Use this guide when Codex is your main local harness and you want Guard to stop changed MCP servers before the Codex CLI launches.
What Guard detectsDirect link to What Guard detects
The Codex adapter reads:
~/.codex/config.toml<workspace>/.codex/config.toml
From those files Guard inspects mcp_servers entries, records one artifact per server, and keeps the scope clear:
globalwhen the config comes from your home directoryprojectwhen the config lives inside the current workspace
Guard preserves the configured transport:
stdiowhen the server declares acommandhttpwhen the server declares aurl
Approval modelDirect link to Approval model
Codex currently uses the Guard approval center as its main approval surface.
- approval tier:
approval-center - current summary: Guard owns artifact approval today and can hand blocked changes to the local approval center
- fallback path: use the local approval center now, then move longer-term approval UX onto Codex App Server when that path is available
Install and launch flowDirect link to Install and launch flow
Use the standard Guard wrapper flow:
hol-guard detect codex --json
hol-guard install codex
hol-guard run codex --dry-run
hol-guard run codex
hol-guard approvals
hol-guard install codex creates a local Guard shim and keeps Codex launch interception outside your repository config. Guard does not rewrite the Codex config itself.
What a blocked change looks likeDirect link to What a blocked change looks like
When Codex config changes introduce a new or changed MCP server:
- Guard snapshots the configured server
- compares it against the last stored state
- resolves the effective policy action
- records a receipt and optional diff
- pauses launch and routes approval through the local approval center when policy blocks
Recommended validation loopDirect link to Recommended validation loop
For a real local canary:
hol-guard detect codex --json
hol-guard install codex
hol-guard status
hol-guard run codex --dry-run
hol-guard receipts
hol-guard diff codex
If you want a stronger first-party canary, point Codex at a local hashnet-mcp-js checkout from ~/.codex/config.toml or <workspace>/.codex/config.toml, then repeat the Guard loop above.
Best fitDirect link to Best fit
Codex is a good Guard fit when you want:
- clean config discovery from TOML
- explicit project-vs-global MCP server scope
- local receipt-backed approval before Codex starts