--max-warnings global limit without per-rule exclusion

Short Answer

No. --max-warnings N cannot be scoped to a subset of rules or rule groups. ESLint sums every message whose final severity is warn across all linted files and compares that single total against N. There is no supported CLI option or configuration key—in either eslintrc or flat config—that excludes specific rules from the count while still reporting them.

Confirmed Behavior vs. Design Inference

Confirmed: the threshold applies to the aggregate warning count of the run; errors are tracked separately and always produce a non-zero exit regardless of the warning budget. Rules set to off emit no messages and contribute nothing. Plugin-authored rules participate in the same aggregation as core rules because the count is computed from the final result set, not from rule provenance.

The consistency across config formats follows from that design: since the total is derived from completed lint results, the configuration engine does not change how warnings are tallied. This reflects ESLint 8.x-era behavior; re-verify flag interactions after any major version upgrade.

Workarounds for Rule-Specific Budgets

Because the boundary cannot be drawn inside ESLint, move it outside:

• Two-pass runs: run ESLint once with only the budgeted rules enabled at warn, applying --max-warnings; run a second pass with all rules at warn and no limit for informational reporting. This roughly doubles lint time and requires maintaining two configurations or override sets.
• Post-process JSON output: run with -f json, filter messages by ruleId in a small script, and enforce your own threshold. Preserve native exit-code handling so genuine errors still fail the pipeline—a custom script that swallows the exit code can mask real failures in CI.

Verification Steps

Confirm the aggregation in your own setup:

1. With at least one rule at warn, run npx eslint . --max-warnings 0 and check that the exit code is non-zero.
2. Set that rule to off and rerun; the exit code should become zero.
3. Switch the same rule to error and rerun with a high --max-warnings value; the exit should remain non-zero.
4. Repeat the first step with identical severities in both an .eslintrc file and an eslint.config.js flat config to confirm the count matches.

One detail that changes the recommendation: whether your CI can execute a Node.js post-processing step for the JSON output, or whether you need a pure-CLI pipeline, which pushes you toward the two-pass approach.