Go Build Cache on Mac: Is It Safe to Delete?
Low riskPackage managers & build toolsUpdated
- Location
~/Library/Caches/go-build
- Risk level
- Low riskRebuilt automatically by macOS or the app that made it. Freshist selects these for you — you still see every item before anything moves.
- Selected by default
- Yes
- What Freshist does
- Moves the selected items to the Trash, so you can undo. Nothing is deleted outright.
- In the app
- Clean → Go Build Cache — “Go build cache — next builds recompile and take longer.”
From Freshist's own cleaning rules — the same catalog the app uses.
What lives in the Go build cache
Since Go 1.10, the go command caches build outputs so it can reuse them across builds and across projects. The default location is a go-build folder inside the operating system's user cache directory, which on macOS is ~/Library/Caches/go-build. The GOCACHE environment variable overrides it.
The cache holds:
- Compiled package archives for your packages, their dependencies and the standard library, keyed by a hash of the inputs (source, flags, Go version, build tags).
- Cached test results.
go testin package list mode caches successful results and replays them when nothing relevant changed, shown as(cached)in the output. - Other build metadata, such as cgo outputs and vet results.
The files are named by hash in two-character subfolders (00/ to ff/), so browsing them tells you nothing useful.
What makes it grow
Every combination of package, Go version, build flags and target platform creates new entries. Cross-compiling with different GOOS/GOARCH values, using -race, building with several Go toolchains, or running tools like gopls and linters that build packages all add more. Large dependency graphs (Kubernetes clients, cloud SDKs) take a lot of compiled output.
The go command does trim the cache: its documentation says it periodically deletes cached data that hasn't been used recently. The trimming is gradual, so a cache built up over a busy month can stay large for a while.
What happens if you delete it
| Effect | Details |
|---|---|
| Next build | Recompiles everything, including the standard library for your settings |
Next go test | Runs every test again; no (cached) results |
| Editor tooling | gopls rebuilds its data, so analysis feels slow briefly |
Source code, go.mod, go.sum | Not affected |
| Downloaded modules | Not affected; they live in GOMODCACHE |
Installed binaries in ~/go/bin | Not affected |
What you lose is time: on a big project, the first build afterwards can take several minutes.
Locate both caches
go env GOCACHE GOMODCACHE # where each cache actually is
du -sh "$(go env GOCACHE)"
du -sh "$(go env GOMODCACHE)"
If you set GOCACHE yourself, these commands show your custom path, not the default.
Clear it with the go command
go clean -cache
The go command documentation says -cache removes the entire go build cache. Related flags do narrower jobs:
go clean -testcacheexpires all test results but keeps compiled packages.go clean -fuzzcacheremoves cached fuzzing values. The docs note that fuzzing may be less effective for a while afterwards.go clean -modcacheremoves the module download cache, a different folder covered in the FAQ.
Stop long-running builds and editors first, since gopls may be writing to the cache.
When a warm cache matters
Keep it if you're mid-project and rely on fast incremental builds, or if you're about to run a long test suite where cached results save real time. Clear it when you switch Go versions and have outgrown the old one, after a lot of cross-compiling, or when you suspect a stale cache entry (rare, but go clean -cache is the standard fix). Rust keeps a similar download cache, covered in the Cargo registry cache guide, and developer caches on Mac compares them all.
Sources
Frequently asked questions
Is the Go build cache the same as the module cache?
No. Downloaded module source lives in GOMODCACHE, by default ~/go/pkg/mod. That's a separate folder, cleared with go clean -modcache, and clearing it means re-downloading every dependency.
Why can't I delete files in ~/go/pkg/mod with Finder?
The go command marks module cache files read-only to protect them from edits. Use go clean -modcache instead of fighting the permissions. The build cache in ~/Library/Caches/go-build doesn't have that issue.
Do I need to clear the cache to force tests to run again?
No. go clean -testcache expires cached test results without removing compiled packages, and go test -count=1 skips the test cache for one run.