openai/codex · error · ConstraintError

invalid rules in requirements (set by {requirement_source}):

Error message

invalid rules in requirements (set by {requirement_source}): {reason}

What it means

ConstraintError::ExecPolicyParse (codex-rs/config/src/constraint.rs:25) wraps a parse failure of the exec policy rules inside a requirements layer. The requirement_source in the message identifies which requirements file (system, user, cloud/managed) carries the broken rules; reason is the underlying parse error.

Source

Thrown at codex-rs/config/src/constraint.rs:25

#[derive(Debug, Error, PartialEq, Eq)]
pub enum ConstraintError {
    #[error(
        "invalid value for `{field_name}`: `{candidate}` is not in the allowed set {allowed} (set by {requirement_source})"
    )]
    InvalidValue {
        field_name: &'static str,
        candidate: String,
        allowed: String,
        requirement_source: RequirementSource,
    },

    #[error("To use model `{model}`, you need to use auto review.")]
    AutoReviewRequired { model: String },

    #[error("field `{field_name}` cannot be empty")]
    EmptyField { field_name: String },

    #[error("invalid rules in requirements (set by {requirement_source}): {reason}")]
    ExecPolicyParse {
        requirement_source: RequirementSource,
        reason: String,
    },

    #[error(
        "invalid requirement for MCP server `{server_name}` (set by {requirement_source}): {reason}"
    )]
    McpServerRequirementParse {
        server_name: String,
        requirement_source: RequirementSource,
        reason: String,
    },
}

impl ConstraintError {
    pub fn empty_field(field_name: impl Into<String>) -> Self {
        Self::EmptyField {

View on GitHub (pinned to 339751715c)

Solutions

Open the requirements file named by requirement_source and fix the rules stanza according to the reason text
Dry-parse the corrected rules against the current exec-policy schema before redeploying
Redeploy the fixed requirements through the same channel (cloud/MDM/system file)

Defensive patterns

Strategy: validation

Validate before calling

// Dry-parse a requirements file before shipping it
let _: RequirementsToml = toml::from_str(&requirements_str)
    .map_err(|e| format!("requirements would fail to load: {e}"))?;

Try / catch

match build_constraints(...) {
    Err(ConstraintError::ExecPolicyParse { requirement_source, reason }) => {
        eprintln!("fix rules in {requirement_source}: {reason}");
    }
    r => r?,
}

Prevention

Round-trip managed requirements through a strict parse in CI before deployment
Version requirements payloads alongside the codex version that consumes them
Generate requirements files instead of hand-editing TOML

When it happens

Trigger: Loading a requirements TOML whose exec policy rules table does not match the expected rule schema: wrong executor pattern, missing required keys, or wrong value types; the constraint system parses the rules from that RequirementSource during config load.

Common situations: An admin hand-edits managed requirements and introduces a syntax or type error; schema drift between an older requirements file and a newer codex build; exec rules copy-pasted from docs of a different version.

Related errors

AI-assisted analysis of openai/codex@339751715c (2026-08-25). Data as JSON: /api/errors/f3b2416c8d6e4461. Report an issue: GitHub.