It runs a command you define, once per generated file, passing the file path as the argument. It is opt in: you must both set a language specific environment variable and turn on the option. Because the command is arbitrary, treat the variable as executable configuration and lock it down in CI.
What the feature is for
Generators produce code that is not always formatted the way your team wants. The post-processing feature hands each file to a formatter or linter. The project's own example sends generated Ruby files to a code style tool that fixes them in place.
The documentation lists supported environment variables by language, with names in the pattern LANGUAGE_POST_PROCESS_FILE, covering languages such as Go, Java, Python, Rust, Kotlin, Swift and TypeScript.
How it is switched on
Two things must both be true:
- The relevant environment variable holds the command.
- The tooling option is enabled, which is a CLI flag or a plugin setting.
The docs state that this is opt in for security. They also note that files are processed one at a time, and that the external tool may be a custom script that invokes several tools.
export RUBY_POST_PROCESS_FILE="/usr/local/bin/rubocop -a"
openapi-generator generate --enable-post-process-file -i spec.yaml -g ruby -o out/
Where the risk sits
The command line in the variable is run by the generator process, with the permissions of whoever runs the build. Anyone who can change that variable, or the script it points to, can run code in your pipeline.
| Scenario | Risk |
|---|---|
| Variable set in a shared CI template | A change there affects every project using it |
| Variable points to a script in the repo | A pull request can change what runs |
| Variable set in a developer shell profile | Output differs between machines, hard to reproduce |
| Formatter fetched on the fly | The build depends on whatever the network returns |
None of this is a flaw in the feature. It is how any build hook works. The point is to place it under the same review as other build scripts.
Safe handling
- Point the variable at a pinned tool installed from your own registry, with the version recorded.
- If you use a wrapper script, keep it in the repository, require review for changes and make it do nothing but call formatters.
- Set the variable in the CI job definition, not in the developer profile, so everyone gets the same result.
- Run the generate step with the narrowest permissions the job allows. It does not need deploy credentials.
- Compare the formatted output to a committed copy and fail on drift. That also catches a changed formatter version.
If you do not need formatting at generation time, leave the option off and format in a normal lint step that you already control.
Related reading
For the broader picture of what lands in a generated client, see dependency risk in generated clients and custom templates and who to trust.
Where Safeguard fits
Safeguard's policies and gates run on pull requests, so changes to build scripts and pipeline files can be held for review alongside code. Dependency scanning covers the tools your build installs when they are declared in the repository.
Quick check
Does the generator run a post-process command by default?
No. The documentation says it requires both the environment variable and the enabling option, and describes it as opt in for security.
Is a formatter on generated files a vulnerability?
Not by itself. The concern is who controls the command and where the tool comes from.
Sources
Last reviewed: 19 October 2026.
