The trimpath flag removes file system paths from a Go executable, so the binary no longer records the directory it was built in. The buildvcs flag controls whether version control details are stamped in. Together they remove two build machine details that can make the same source produce different binaries.
What each flag does
Both flags are documented in the Go command reference.
| Flag | What the docs say |
|---|---|
| trimpath | Removes all file system paths from the executable. Recorded file names begin with a module path and version when using modules, or a plain import path for the standard library or GOPATH |
| buildvcs auto (default) | Stamps version control information if the main package, the main module and the current directory are all in the same repository |
| buildvcs false | Always omit version control information |
| buildvcs true | Error out if version control information is not available |
Without trimpath, the path of your checkout can end up in debug information and panic messages. A build in a directory named after a CI job then differs from a build on a laptop, even though the source is identical.
Why paths matter for reproducibility
The Go team's post on reproducible toolchains lists relevant inputs to a build. Two of them are the name of the directory containing the source code, which may appear in debug information, and the user and group of the account running the build, which may appear in archive metadata. The post calls an input unintentional when it turns out to be relevant but nobody meant it to be.
Your application build can have the same problem. The Go team removed these inputs from the toolchain itself, so that its only relevant input is the source. You can get close for your own binary with a few settings.
A small, repeatable build recipe
- Pin the Go version your build uses, so a different compiler is not an input. See what the go line and toolchain line in go.mod mean.
- Build with trimpath.
- Decide on buildvcs. If you want the commit recorded, keep the default and build from a clean checkout. If you want the binary to depend only on file contents, set it to false.
- Build twice from different directories and compare checksums.
go build -trimpath -buildvcs=false -o app ./cmd/app
sha256sum app
Keeping the commit in the binary is valuable for incident response, since you can tell which source a running binary came from. The trade off is that a dirty working tree is also recorded, so a build from an uncommitted state will differ. Choose deliberately and write the choice in your build documentation.
What this does not fix
Trimpath hides local paths, but a binary built with different dependencies or a different compiler is still different. Keep go.sum and your module graph under review, and build in a controlled environment. If you use cgo, the C compiler and libraries become inputs as well, and their own path settings apply. See how to stop build paths leaking from C compilers.
Try it yourself
Safeguard's SBOM and dependency scanning is generally available and reads Go modules among other ecosystems. The demo walks through a dependency inventory so you can see what a scan reports for each component.
Click through it at your own pace, or open it full screen.
Quick check
Does trimpath make a Go build reproducible on its own?
No. It removes local paths. Compiler version, dependencies and build flags still matter.
Should I turn buildvcs off for release builds?
It depends. Off removes repository state as an input. On records the commit, which helps trace a binary to its source.
Sources
Last reviewed: 19 October 2026.
