openai/codex · error · ConstraintError

invalid value for `{field_name}`: `{candidate}` is not in th

Error message

invalid value for `{field_name}`: `{candidate}` is not in the allowed set {allowed} (set by {requirement_source})

What it means

ConstraintError::InvalidValue (codex-rs/config/src/constraint.rs:9) is produced by the Constrained<T> validators that config requirements install on fields. When a caller proposes a value for a constrained field, the validator rejects any candidate not in the allowed set; the error names the field, the allowed set, and the RequirementSource (the system/user/cloud/managed requirements file) that imposed it.

Source

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

use std::fmt;
use std::sync::Arc;

use crate::config_requirements::RequirementSource;
use thiserror::Error;

#[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,

View on GitHub (pinned to 339751715c)

Solutions

  1. Change the value to one of the entries printed in the allowed set in the message
  2. Have the owner of the requirement source named in the error widen the allowed set if the value is legitimate
  3. Remove or correct the user-level override that conflicts with the managed requirement

Example fix

# user config.toml (before)
sandbox_mode = "danger-full-access"   # not in allowed set

# (after)
sandbox_mode = "workspace-write"
Defensive patterns

Strategy: validation

Validate before calling

// Constrained exposes a pre-check: probe before committing the edit
if let Err(e) = constrained.can_set(&candidate) {
    // show the allowed set from the error instead of mutating config
    return Err(e.into());
}
constrained.set(candidate)?;

Try / catch

match constrained.set(candidate) {
    Err(ConstraintError::InvalidValue { field_name, allowed, requirement_source, .. }) => {
        eprintln!("{field_name} must be one of {allowed} (per {requirement_source})");
    }
    r => r?,
}

Prevention

When it happens

Trigger: Setting a requirements-constrained field (sandbox mode, approval policy, model, etc. via config.toml, CLI flag, or API set) to a value outside the set declared in a requirements layer; Constrained::new / can_set / set runs the validator and returns Err(InvalidValue).

Common situations: Enterprise requirements pin sandbox_mode to {workspace-write} while the user's config requests something else; an MDM profile narrows allowed models; user config conflicting with a system or managed requirements file after joining an org.

Related errors


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