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
- Change the value to one of the entries printed in the allowed set in the message
- Have the owner of the requirement source named in the error widen the allowed set if the value is legitimate
- 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
- Read the effective requirements layer before offering values in config UIs so choices are pre-filtered to the allowed set
- Call can_set before applying user edits so failures carry context
- Log the requirement source on rejection so users know whom to contact
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
- To use model `{model}`, you need to use auto review.
- field `{field_name}` cannot be empty
- failed to decrypt encrypted task id
- invalid cloud config fragment {fragment}: {message}
- invalid requirement for MCP server `{server_name}` (set by {
AI-assisted analysis of openai/codex@339751715c (2026-08-25).
Data as JSON: /api/errors/8d53f0f300530c5e.
Report an issue: GitHub.