The go mod verify command checks that the module zip files and extracted directories in your local module cache still match the hashes recorded when they were first downloaded. It detects changes to the cache after download. It does not download modules you do not have, and it does not use go.sum to verify module content.
The exact wording
The Go modules reference says go mod verify checks that module zip files and their extracted directories have hashes that match hashes recorded in the module cache when they were first downloaded. It is useful for detecting changes to files in the module cache after a module has been downloaded and verified.
Two caveats from the same page matter. It does not download content for modules not in the cache. And it does not use go.sum files to verify module content, though it may download go.mod files for minimal version selection, and it uses go.sum to verify those.
Two different checks people mix up
Go has more than one integrity mechanism, and they answer different questions:
- go.sum and the checksum database: When the go command first downloads a module, it can authenticate it against the public checksum database. The GOSUMDB variable sets its name, URL and key, and the default is sum.golang.org. This answers whether you got the same bytes as everyone else.
- go mod verify: Checks that what is on your disk now still matches what was recorded when it arrived. This answers whether something touched your cache.
The reference also notes that version lists and version metadata returned for info requests are not authenticated and may change over time.
When to run it on a laptop
Running it makes sense in a few situations:
- After restoring a laptop from a backup or copying a home directory.
- After a suspected compromise, to see whether cached modules were altered.
- When you used the modcacherw build flag. The reference warns developers to be careful not to change files in the module cache, because that setting makes them writable.
The expected result is a message that all modules are verified. Anything else is worth investigating before you trust a build from that machine.
What it will not tell you
A clean result does not mean your dependencies are safe. If a module was malicious on first download, the recorded hash is of the malicious content. The command checks consistency, not trustworthiness. For that you need vulnerability data and a review of what your build actually pulls in.
Private modules
The reference also describes variables for modules that should not be looked up in the public database, such as GONOSUMDB. Use those deliberately for private module paths, and keep the list narrow, so you do not switch off authentication for more than you intend.
If you want a quick look at what your projects actually resolve, Safeguard offers SBOM and dependency scanning, and there is a free scan at gold.safeguard.sh/scan.
Quick check
Does go mod verify fetch missing modules?
No. The Go reference says it does not download content for modules that are not in the cache.
Is the checksum database the same as go mod verify?
No. The checksum database authenticates a module when first downloaded. go mod verify checks the local cache against hashes recorded at download time.
Sources
Last reviewed: 19 October 2026.
