Review a regeneration diff in a fixed order: dependency and build files first, then authentication and HTTP client code, then removed or renamed operations, and last the bulk of model changes. Most of the lines are noise, but a few files carry the risk.
Why diffs get big
A regeneration touches every file the template emits. Even a small spec change can reorder fields or rename helpers across many files. If the generator version changed too, almost everything differs. That is why you should change the spec and the generator in separate pull requests, as described in how to pin the OpenAPI Generator version in CI.
The review order
| Step | Files | What you are checking |
|---|---|---|
| 1 | Build files such as pom, gradle, package manifests | New or bumped libraries, loosened version ranges |
| 2 | Client and configuration classes | Authentication handling, base URL, TLS and certificate options, timeouts, redirect behaviour |
| 3 | Files for removed or renamed operations | Breaking changes for callers, and security operations that vanished |
| 4 | Serialisation and JSON helper code | Lenient parsing, unsafe type handling |
| 5 | Models and docs | Spot check only |
Step 2 deserves the most care. A client is the part of your product that sends credentials, so a changed default there matters more than a hundred new model fields.
Use the manifest the generator writes
The generator writes a .openapi-generator folder into the output, which the project's own post-processing example shows containing VERSION and FILES entries. Committing these gives a record of the tool version and the files it produced. A diff that shows files appearing or disappearing in that list tells you quickly what the generator added or dropped.
Add checks around the diff
- Regenerate in CI and fail if the tree is dirty. This catches hand edits that would be overwritten and generator drift.
- Run dependency scanning on the result, not only on the spec.
- Run your static analysis on generated code, or decide explicitly to exclude it. Our post on SAST exclusions for generated code explains the trade off.
- Keep hand written changes out of generated files. Use the ignore file so regeneration does not overwrite them, and record why each exclusion exists.
What a clean diff looks like
A diff you can approve in a few minutes has these traits: no new dependencies, no change to client or auth files, additions only in models and operations that match a spec change, and a generator version that is unchanged. When any of those fails, slow down.
Where Safeguard fits
Safeguard scans pull requests for dependency changes and applies policy gates, so a regenerated client that pulls in a vulnerable library is flagged before merge. Its reachability analysis helps separate libraries your code actually calls from ones that merely sit in the tree.
Try it yourself
Click through it at your own pace, or open it full screen. Look for the list of components a project pulls in, which is what step 1 of the review should compare.
Quick check
Should generated code be committed?
Often yes, because it makes the diff reviewable. The alternative is generating at build time, which we compare in a separate post.
Who should review a regeneration pull request?
Someone who owns the API and someone who knows the client language. The first checks the spec change, the second the client code.
Sources
Last reviewed: 19 October 2026.
