ai-guard: refresh Codex surface — layered config, granular approval_policy, rules DSL, requirements.toml

[Ju571nK]

Motivation

Sigil's Codex parser reads ~/.codex/config.toml and treats approval_policy / trust_level as its autonomy signals. Codex has since layered its configuration and added new approval surfaces, so a single-file read now misses config that actually governs the session. Verified against openai/codex main (codex-rs/config/src/loader/mod.rs, config_requirements.rs, mcp_types.rs) and https://learn.chatgpt.com/docs/config-file/config-reference , plus this machine running codex-cli 0.137.0.

Gaps

1. approval_policy is no longer always a string. Besides "untrusted" | "on-request" | "never" it accepts a table: { granular = { sandbox_approval, rules, mcp_elicitations, request_permissions, skill_approval } }. A parser assuming a scalar either misses it or errors. ("on-failure" is now documented as deprecated.)

2. Config is a layer stack, not a file. Ascending precedence: platform managed prefs → /etc/codex/config.toml (or %ProgramData%\OpenAI\Codex\config.toml) → enterprise bundle → ${CODEX_HOME}/config.toml → profile ${CODEX_HOME}/<name>.config.toml → ${PWD}/config.toml → ./.codex/config.toml walking up to the git root. Project-local layers are skipped for untrusted dirs, and the project-local denylist covers openai_base_url, model_provider(s), notify, profile(s), otel — but not mcp_servers, hooks, or approval_policy. So a cloned repo can contribute MCP servers and lifecycle hooks. That is the same shape as the Amazon Q issue (CVE-2026-12957), where a workspace-supplied .amazonq/mcp.json auto-loaded without consent. Sigil should read the layers it can and report which contributed a finding.

3. New file: ~/.codex/rules/*.rules. Confirmed present on this machine as ~/.codex/rules/default.rules containing a command-approval DSL:

prefix_rule(pattern=["codex", "mcp", "login"], decision="allow")

A decision="allow" entry on a broad or dangerous prefix is a persistent auto-approval that never prompts — readable, and squarely in the same family as defaultMode/approval_policy. Needs a small parser for the DSL (or at minimum, extraction of decision="allow" prefixes).

4. codex remote-control — headless app-server orchestration with daemon start/stop and pairing, i.e. the CLI can be driven unattended from elsewhere. The admin constraint is allow_remote_control in requirements.toml. Pairing/daemon state on disk is a candidate detection surface (exact location not yet verified — needs hardware confirmation before any rule is written).

5. requirements.toml (/etc/codex/, %ProgramData%\OpenAI\Codex\) — admin-enforceable constraints including approval_policy, permission_profile, allow_managed_hooks_only, allow_remote_control, mcp_servers, plugins, marketplaces, exec_policy, network, filesystem. Presence is a hardening signal worth reporting positively.

6. Lifecycle hooks in Codex config — events PreToolUse, PermissionRequest, PostToolUse, PreCompact, PostCompact, SessionStart, SubagentStart, SubagentStop, UserPromptSubmit, Stop; discovered per config layer in both TOML and JSON folder form, including plugin-provided hooks. Two consequences: repo-local hooks are an injection surface to flag, and this is also where a Codex enforcement adapter would eventually attach. (The key was renamed features.codex_hooks → features.hooks.)

7. MCP per-server config grew — bearer_token / bearer_token_env_var (plaintext credentials in config), auth, enabled_tools/disabled_tools, and per-tool approval_mode. default_tools_approval_mode is auto | prompt | writes | approve with serde default Auto. Note writes mode keys off readOnlyHint, which is server-supplied metadata — a poisoned tool can declare itself read-only to skip approval. That detection belongs with the tool-metadata work (see the #148 follow-up issue), but the config-side signal (writes mode in use) is readable here.

8. /import migrates settings, MCP servers, and plugins from Cursor and Claude Code, so a finding in one agent's config can propagate into Codex. Worth noting in remediation text rather than a separate check.

Scope

Mechanism only. Codex parser: tolerate the table form of approval_policy, walk the layer stack, add the rules DSL source, surface requirements.toml as a hardening signal, and record which layer produced each finding. Remote-control detection is gated on hardware verification of where its state lands.

[Ju571nK]

Correction to the opening paragraph: the Codex parser does not currently read approval_policy or trust_level. It reads sandbox_mode, [hooks], and [mcp_servers] only — verified by grep across crates/. The autonomy keys were mapped as detectable in earlier research but never wired up.

That makes gap 1 larger than written: it is not "tolerate the new table form", it is "read the key at all, in both its string and { granular = … } forms". The rest of the issue stands.

[Ju571nK]

PR #206 covers gap 1 (partly) and gap 3: approval_policy is now read — "never" is an auto-approval finding — and ~/.codex/rules/*.rules decision="allow" rules are reported as standing command approvals. Verified against codex-cli 0.137.0 on a live install.

Deliberately left for follow-up, so this issue stays open:

• Gap 1 remainder — the { granular = … } form. It parses without error but is not scored. A granular policy can be stricter than any scalar, so asserting auto-approval from its shape alone would claim an exposure that may not exist. Scoring it needs hardware verification of what the sub-keys accept.
• Gap 2 — the config layer stack. /etc/codex/config.toml, profile files, and repo-local ./.codex/config.toml (which can contribute mcp_servers and hooks, since neither is on the project-local denylist).
• Gap 4 — codex remote-control. Still gated on verifying where its pairing state lands on disk.
• Gap 5 — requirements.toml. Same blocker as ai-guard: refresh Claude Code surface — auto mode, autoMode rules block, non-command hooks, loop.md #199 gap 6: it is a positive hardening signal and the rubric only scores risk.
• Gaps 6–8 — lifecycle hooks per config layer, the MCP per-server key growth, and readOnlyHint. The last belongs with #148 follow-up: MCP tool-metadata baseline/drift, server_info source, readOnlyHint contradiction #201, where the tool metadata already gets read.

One correction worth surfacing from the review: an early draft of the rules parser was line-based and split pattern=["codex","mcp","login"] into three findings. That list is a single argv sequence — the rule approves the command codex mcp login, not three separate commands — so the shipped parser is quote- and bracket-aware and reports one. A nested list is a set of alternatives at that position and renders as gh pr {view|list}.

[Ju571nK]

Gap 5 (requirements.toml as a hardening signal) is split out to #207 — same design blocker as #199 gap 6. This issue keeps the granular approval form, the config layer stack, remote-control state, and the per-layer hooks / MCP key growth.