Files matched by the ignore file are skipped when you regenerate, so improvements and fixes in newer templates never reach them. That is the point of the file, and also its cost. Keep the list short, record why each entry exists, and review ignored files by hand on every generator upgrade.
What the file does
OpenAPI Generator supports a .openapi-generator-ignore file that works like a gitignore. It must sit in the root of the output directory. It gives finer control over overwriting existing files than the skip overwrite flag does, because you can name individual files or directories.
The docs show patterns for a file anywhere, a file in the root, recursive directory excludes and negations that re-allow a file. They also note a CLI option that overrides the ignore file location, described as a complete override, most useful on initial generation.
There is a related option to pre populate the ignore list during generation, for example with README and build files.
Why people use it
- To keep hand written changes, such as a custom retry wrapper, safe from regeneration.
- To skip generated tests or docs they do not want.
- To keep a build file they maintain themselves.
All reasonable. The trouble starts when the ignored files stay frozen while everything around them moves.
The security cost of ignoring files
| Ignored file | What can go wrong |
|---|---|
| Build file such as pom or manifest | Dependencies stay at old versions after the generator updates them |
| HTTP client or configuration class | A fix to TLS, redirect or auth handling in newer templates never arrives |
| Serialisation helper | Parser fixes are skipped |
| Hand edited model | Drifts from the spec, so new fields or constraints are missing |
An ignored build file is the most common case. The generator may raise a library version to fix a known issue, but your copy never sees it, and your scanner keeps reporting the old one.
A workable practice
- Keep the ignore list as short as you can. Prefer adding behaviour in a separate wrapper file you own rather than editing a generated one.
- Next to the file, record each entry with a reason and an owner. A plain comment line works, since comments start with a hash.
- On every generator upgrade, regenerate into a scratch directory and diff each ignored file against the fresh version. Port needed changes by hand.
- Run dependency scanning over the real tree, so an ignored build file still gets checked.
- Review the ignore file itself in pull requests. Adding a broad pattern is a security relevant change.
Spotting a stale ignored file
Compare the generator version recorded in the output with the version in your pinned config. If they differ and ignored files exist, you have work to do. The post on what to check in a regeneration diff covers the diff itself.
Where Safeguard fits
Safeguard's dependency scanning reads the manifests in your repository as they are, ignored or not, so a frozen build file with a known vulnerable library still appears in the inventory. Autonomous remediation can open fix pull requests, off by default and with every category on Manual.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a finding is paired with an available fixed version.
Quick check
Is the ignore file the same as skip overwrite?
No. The skip overwrite flag stops overwriting existing files in general. The ignore file lets you choose which files to protect.
Where does the ignore file live?
In the root of the output directory, according to the documentation.
Sources
Last reviewed: 19 October 2026.
