circleci config validate or circleci config process can fail with a config-too-large error on a tree whose pipelines still run. CircleCI does not count commits when it validates or compiles config. A repository with a very large .git directory can make checkout slow. That size is separate from the config limit.
The error means the compiled config is over the Cloud cap. Pipelines that still run have already compiled under that cap. Local validate can still fail on the same tree when the CLI expands more than the pipeline did.
What the CLI sends
circleci config validate and circleci config process send the YAML plus resolved orbs. They do not upload git history.
Cloud limits are 6 MB for the source config and 8 MB for the compiled config (orbs inlined, anchors and aliases expanded, matrices expanded).
Why local validate can be stricter than the pipeline
The CLI compiles a larger document when any of these differ from the pipeline run:
No
--pipeline-parameters, so defaults expand differently than the trigger didThe whole
.circleci/directory is packed, instead of the single setup file the pipeline compiledThe command is pointed at a continuation config instead of the setup config
A commit that only deletes lines can still trip the local command if that commit changes which file, parameters, or orbs the CLI expands.
What to do
Run validate against the same file the pipeline uses (the setup config, not a continuation file), and pass the same pipeline parameters the trigger uses.
If the pipeline runs and local validate still fails after that, compare the compiled size of each path. The pipeline’s compiled config is the one that must stay under 8 MB.
Shrink the compiled document (fewer inlined orb jobs, smaller matrices, split continuation configs) when the pipeline itself starts failing the cap.
Related: Why job names get a -1 or -3-1 suffix describes a different compiler behavior and does not change the size cap.