# Go Build Cache on Mac: Is It Safe to Delete?

> ~/Library/Caches/go-build stores compiled Go packages and cached test results. Deleting it is safe; go clean -cache is the supported way.

- Updated: 2026-10-10
- URL: https://fresh.ist/caches/go-build/

**TL;DR:** You can delete it. ~/Library/Caches/go-build is GOCACHE, where the go command keeps compiled packages and successful test results so it doesn't redo work. It contains no source code and no downloaded modules. After you clear it, the next go build or go test recompiles from scratch and runs every test again. The supported command is go clean -cache.

## Facts from the Freshist app

- Category in Clean: Go Build Cache — "Go build cache — next builds recompile and take longer."
- Location: `~/Library/Caches/go-build`
- Risk level: Low risk — Rebuilt 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.

## 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 test` in 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

```sh
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

```sh
go clean -cache
```

The [go command documentation](https://pkg.go.dev/cmd/go#hdr-Remove_object_files_and_cached_files) says `-cache` removes the entire go build cache. Related flags do narrower jobs:

- `go clean -testcache` expires all test results but keeps compiled packages.
- `go clean -fuzzcache` removes cached fuzzing values. The docs note that fuzzing may be less effective for a while afterwards.
- `go clean -modcache` removes 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](/caches/cargo/) guide, and [developer caches on Mac](/blog/developer-caches-mac/) compares them all.

## Sources

- [go command docs: build and test caching](https://pkg.go.dev/cmd/go#hdr-Build_and_test_caching)
- [go command docs: go clean](https://pkg.go.dev/cmd/go#hdr-Remove_object_files_and_cached_files)
- [Go Modules Reference: module cache](https://go.dev/ref/mod#module-cache)

## 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.

---

Canonical page: https://fresh.ist/caches/go-build/
Official site: https://fresh.ist/ (fresh.ist only)
Generated: 2026-10-10