If go.mod changed after you last ran go mod vendor, Go reports an error because vendor/modules.txt no longer matches. The fix is to run go mod vendor again and commit the result. Vendoring switches on automatically when a vendor directory exists and the go version in go.mod is 1.14 or higher.
What go mod vendor produces
The Go modules reference says go mod vendor constructs a directory named vendor in the main module's root, containing copies of all packages needed to build and test packages in the main module. It also creates vendor/modules.txt, which lists the vendored packages and the module versions they were copied from.
When Go uses the vendor directory
Go uses it automatically if a vendor directory is present in the main module's root and the go version in go.mod is 1.14 or higher. You can control this with the mod flag:
| Flag | Effect |
|---|---|
-mod=vendor | Force use of the vendor directory |
-mod=readonly | Do not use it, and do not update go.mod |
-mod=mod | Do not use it, and allow go.mod updates |
You can set the flag through the GOFLAGS environment variable, such as GOFLAGS=-mod=vendor, so every command in CI behaves the same way.
The consistency check
When Go reads modules.txt, it checks that the module versions are consistent with go.mod. If go.mod has changed since modules.txt was generated, Go reports an error and tells you to run go mod vendor again.
This is a feature. It stops the case where someone bumps a version in go.mod, forgets to refresh vendor, and CI builds the old code.
Fix it in four steps
- Run
go mod tidyso go.mod and go.sum are correct. - Run
go mod vendor. - Review the diff of vendor/modules.txt and the changed source files.
- Commit go.mod, go.sum and vendor together.
Make it a CI rule
Add a job that runs go mod vendor and then fails if the working tree changed, for example by running git diff --exit-code. That catches a vendor directory that was edited by hand or not refreshed.
Treat edits inside vendor as suspicious. The directory should be reproducible from go.mod and the module sources, so any hand edit is either a bug or an undocumented patch. For the broader question, read should you vendor dependencies into your repo.
What vendoring does not fix
Vendored code can still contain known vulnerabilities. The update and scanning work stays with you, and the diffs get large. Review them with the same care as first party code.
Safeguard dependency and SBOM scanning can list the modules a repository resolves and flag known vulnerabilities. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Does Go use vendor automatically?
Yes, when the vendor directory exists in the main module root and go.mod declares go 1.14 or higher.
How do I ignore the vendor directory for one build?
Pass -mod=readonly or -mod=mod.
Sources
Last reviewed: 19 October 2026.
