bazelbuild/bazel · error · OptionsParsingException

Flag value '%s' for %s is not allowed by invocation policy.

Error message

Flag value '%s' for %s is not allowed by invocation policy. %sed values are: %s

What it means

Thrown in checkUserValue (repeatable-flag branch) when one of the user's accumulated values for a multiple-use flag is not in the policy-allowed set (allow_values) or is in the disallowed set (disallow_values), and no use_default fallback applies. Each element of the flag's list value is checked individually via isFlagValueAllowed.

Source

Thrown at src/main/java/com/google/devtools/common/options/InvocationPolicyEnforcer.java:866

        ImmutableList.Builder<OptionAndRawValue> invocationPolicyFlagListBuilder)
        throws OptionsParsingException {
      OptionDefinition option = optionDescription.getOptionDefinition();
      if (optionDescription.getOptionDefinition().allowsMultiple()) {
        // allowMultiple requires that the type of the option be List<T>, so cast from Object
        // to List<?>.
        List<?> optionValues = (List<?>) valueDescription.getValue();
        for (Object value : optionValues) {
          if (!isFlagValueAllowed(convertedPolicyValues, value)) {
            if (useDefault) {
              applyUseDefaultOperation(
                  parser,
                  policyType + "Values",
                  option,
                  loglevel,
                  conversionContext,
                  invocationPolicyFlagListBuilder);
            } else {
              throw new OptionsParsingException(
                  String.format(
                      "Flag value '%s' for %s is not allowed by invocation policy. %sed values "
                          + "are: %s",
                      value, option, policyType, policyValues));
            }
          }
        }

      } else {

        if (!isFlagValueAllowed(convertedPolicyValues, valueDescription.getValue())) {
          if (newValue != null) {
            logger.at(loglevel).log(
                "Overriding disallowed value '%s' for %s with value '%s' "
                    + "specified by invocation policy. %sed values are: %s",
                valueDescription.getValue(), option, newValue, policyType, policyValues);
            parser.clearValue(option);
            parser.setOptionValueAtSpecificPriorityWithoutExpansion(origin, option, newValue);

View on GitHub (pinned to e6e199d060)

Solutions

Remove or replace the disallowed value(s) from the command line / .bazelrc / wrapper script for that flag.
If the value is legitimately needed, ask the policy owner to add it to allowedValues (or remove it from disallowedValues).
Diff the flag values the environment injects (bazel's --announce_rc) against the allowed set printed in the error message.

Example fix

# before (policy allows only thinlto)
--features=thinlto --features=legacy-opt

# after
--features=thinlto

Defensive patterns

Strategy: validation

Validate before calling

// Wrapper-side: check every accumulated value of a repeatable flag against the policy set
Set<String> allowed = loadPolicyAllowedValues(flagName);
boolean allAllowed = userValuesFor(flagName).stream().allMatch(allowed::contains);
if (!allAllowed) throw new IllegalArgumentException("Values outside policy for " + flagName);

Try / catch

Catch OptionsParsingException; parse the '%sed values' list from the message (or load the policy directly) and diff it against the flag's accumulated values from the command line, project .bazelrc, and user ~/.bazelrc to find the violator.

Prevention

Use --announce_rc to see every value a repeatable flag accumulates before policy checks it
Keep .bazelrc entries for restricted list flags in sync with the policy allow-list
Policy owners: add use_default or newValue to auto-remap instead of hard-failing

When it happens

Trigger: User passes a repeatable flag (e.g. --define-style / list flag) multiple times where at least one value is outside the policy's allowedValues or inside disallowedValues, and the policy has no useDefault (and no newValue, per the branch order).

Common situations: CI policies restricting list flags (e.g. only certain --features allowed) while user .bazelrc or scripts append broader values, partial migration where some tooling still passes legacy values, policy allow-lists drifting out of sync with new valid values.

Related errors

AI-assisted analysis of bazelbuild/bazel@e6e199d060 (2026-08-14). Data as JSON: /api/errors/0eda11847edbb1fe. Report an issue: GitHub.