bazelbuild/bazel · error · OptionsParsingException

Invocation policy is applied after --config expansion, chang

Error message

Invocation policy is applied after --config expansion, changing config values now would have no effect and is disallowed to prevent confusion. Please remove the following policy :

What it means

Thrown when an invocation policy attempts to set the special --config flag. Invocation policies are enforced after --config expansion has already happened, so a policy on --config would silently do nothing; the enforcer throws to make this no-op explicit and prevent user confusion.

Source

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

      throws OptionsParsingException {
    if (invocationPolicy == null) {
      return ImmutableList.of();
    }

    ImmutableSet<String> commandAndParentCommands =
        Preconditions.checkNotNull(
            CommandNameCache.CommandNameCacheInstance.INSTANCE.get(command),
            "Command %s does not exist",
            command);

    // Expand all policies to transfer policies on expansion flags to policies on the child flags.
    List<FlagPolicyWithContext> expandedPolicies = new ArrayList<>();
    OptionPriority nextPriority =
        OptionPriority.lowestOptionPriorityAtCategory(PriorityCategory.INVOCATION_POLICY);
    for (FlagPolicy policy : invocationPolicy.getFlagPoliciesList()) {
      // Explicitly disallow --config in invocation policy.
      if (policy.getFlagName().equals("config")) {
        throw new OptionsParsingException(
            "Invocation policy is applied after --config expansion, changing config values now "
                + "would have no effect and is disallowed to prevent confusion. Please remove the "
                + "following policy : "
                +
            policy
            );
      }

      // These policies are high-level, before expansion, and so are not the implicitDependents or
      // expansions of any other flag, other than in an obtuse sense from --invocation_policy.
      OptionPriority currentPriority = nextPriority;
      OptionInstanceOrigin origin =
          new OptionInstanceOrigin(currentPriority, INVOCATION_POLICY_SOURCE, null, null);
      nextPriority = OptionPriority.nextOptionPriority(currentPriority);
      if (!policyApplies(policy, commandAndParentCommands)) {
        // Only keep and expand policies that are applicable to the current command.
        continue;
      }

View on GitHub (pinned to e6e199d060)

Solutions

Remove the config entry from the policy file.
Express the intent as policies on the flags that --config expands to (e.g. instead of forcing --config=release, set compilation_mode, strip, etc. directly).
If --config must be controlled, do it via .bazelrc rules or wrapper scripts before invocation, not via invocation policy.
Expand the config locally (bazel's --announce_rc or config expansion docs) to find which child flags to target.

Example fix

// before
{"flagPolicy":[{"flagName":"config","setValue":{"flagValue":["release"]}}]}

// after
{"flagPolicy":[{"flagName":"compilation_mode","setValue":{"flagValue":["opt"]}}]}

Defensive patterns

Strategy: validation

Validate before calling

// Reject policies touching --config before deployment
boolean touchesConfig(InvocationPolicy p) {
  return p.getFlagPoliciesList().stream()
      .anyMatch(fp -> fp.getFlagName().equals("config"));
}

Try / catch

Catch OptionsParsingException at startup of the command; treat it as a policy-authoring bug — remove the config entry rather than catching and continuing.

Prevention

Policy the underlying flags, never --config
Expand configs locally first to learn which child flags to target
Add 'config' to a deny-list in policy linters

When it happens

Trigger: Any invocation policy file containing {"flagName": "config", ...} passed via --invocation_policy (or enforced org-wide). The check is a literal string equality on the flag name 'config'.

Common situations: Org policy authors trying to force/forbid specific configurations through --config instead of the underlying flags, porting .bazelrc config sections into policy files, tooling that auto-generates policy from a list of 'locked' flags that happens to include --config.

Related errors

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