The Go build cache on a Mac lives in ~/. It holds compiled packages and test results that the go command reuses, so builds and tests run faster. It's safe to clear: Go rebuilds whatever it needs, and it already removes entries it hasn't used for five days.
The module cache is the other half. Go downloads every module your projects depend on into ~/, inside the go folder in your home folder, along with any newer Go toolchains a project asks for. It has no size limit, and Go never removes anything from it by itself.
Go is a command-line tool with no app of its own. The build cache is a plain folder you can move to the Trash in Finder. The module cache isn't: Go makes its files read-only, so Go's own clean command is the way to remove it, and there's no button for that.
This post covers both caches, what Go's clean command removes with each option, the smaller folders around them, and how to keep the space from coming back.
Where Go keeps its files on a Mac
Go splits its files between your home folder, your Library folder and the place Go itself is installed. Two of them are caches; the rest are things you installed or made.
| What | Where it is | What it holds | Level |
|---|---|---|---|
| Build cache | ~/Library/Caches/go-build | Compiled packages, test results and cached programs | Safe |
| Module cache | ~/go/pkg/mod | Downloaded modules and Go toolchains | Safe |
| Installed programs | ~/go/bin | Programs installed with Go's install command | Leave alone |
| Language server cache | ~/Library/Caches/gopls | Indexes made by gopls, the Go language server | Safe |
| Extra Go versions | ~/sdk | Additional Go releases installed side by side | Review first |
| Go itself | /usr/local/go or Homebrew's folder | The Go release you installed | Leave alone |
A module is Go's word for a versioned collection of packages, usually one repository. Your project's go.mod file lists the modules it needs, and the go command downloads them the first time a build asks for them.
What is the go folder in your home folder?
It's Go's default GOPATH, the folder where Go keeps downloaded modules and installed programs unless you've told it otherwise. Go creates it the first time it needs it, so it appears even if you never made a folder called go.
Inside it, pkg/mod is the module cache and bin holds programs you've installed. A src folder, if there is one, holds code from GOPATH mode, Go's way of working before modules arrived in Go 1.11, and that may be your own code.
How do you open these folders in Finder?
The go folder is visible in your home folder, but your Library folder is hidden. You can open any of these folders directly.
- In Finder, choose Go › Go to Folder.
- Type
~/orLibrary/ Caches/ go-build ~/. The tilde stands for your home folder.go/ pkg/ mod - Press Return.
To see a folder's size, select it and choose File › Get Info. For the module cache, choose View › as List, then View › Show View Options, and select Calculate all sizes, so each folder's size appears in the Size column.
These are Go's default places. If you or a tool has set Go's cache settings, the caches can be elsewhere, so a folder that's small or missing here may simply have moved.
Where does Go show up in Storage settings?
Not by name. System Settings › General › Storage has no category for developer tools. The build cache is in your Library's Caches folder, so it's usually counted in System Data, with the files Storage settings can't name.
The go folder is a visible folder in your home folder, and Apple describes Documents as the files in your home folder that aren't in another category, so the module cache is usually counted there.
The System Data guide explains the rest. Storage settings and the Finder steps here are the same in macOS 26 Tahoe and macOS 27.
Why are the two caches in different places?
They follow different rules. Go puts the build cache in the standard cache folder of the system it runs on, which on a Mac is the Caches folder in your Library. The module cache belongs to the GOPATH, which defaults to the go folder in your home folder on every system.
So the build cache sits with other apps' caches, where macOS and cleanup tools expect to find disposable files. The module cache sits with your own files, where it's easy to see and easy to mistake for something you made.
How much space does Go use?
It depends on how many modules your projects pull in and how much you build. The research behind the app's catalog puts Go's two caches at 1 to 20 GB on Macs that use Go.
Toolchains are easier to measure, because every copy of a release is the same. Here's what the current release takes on a Mac with Apple silicon, depending on how it got there.
- A toolchain Go downloaded into the module cache296 MB · Safe
- Go installed from go.dev240 MB
- The download from go.dev68 MB
Go 1.27.2 for Apple silicon, measured from Go's own downloads on 15 October 2026. In the module cache, a toolchain is kept twice: as the zip file Go downloaded, about 74 MB, and unpacked, about 223 MB.
So each Go release a project asks for adds about 0.3 GB to the module cache, and it stays there until the module cache is cleared.
The Go build cache on a Mac
The go command stores the results of its work in the build cache and reuses them whenever the inputs haven't changed. That's why the second build of a project is so much faster than the first.
What's in the build cache?
- Compiled packages, for your code and every dependency, for each Go version and each set of build settings you've used.
- Test results. Go remembers which tests passed and skips running them again until something they depend on changes.
- Programs run without installing them. Since Go 1.24, programs started with Go's run command and tools started through Go are cached here too. Go's release notes say that makes them start faster at the expense of a larger cache.
- Fuzzing inputs, in a folder called
fuzz. When you fuzz test, Go keeps the inputs that reached new code, and uses them only while fuzzing.
Most of the cache is spread over 256 folders named 00 to ff. Go also leaves a short README in the folder, explaining what it is and naming Go's clean command for when it gets too large.
Does Go clean the build cache by itself?
Yes. Go's documentation says the go command periodically deletes cached data that hasn't been used recently. Its source code sets the details:
| What Go does | When |
|---|---|
| Notes that an entry was used | Each time it's used, at most once an hour |
| Looks for entries to remove | At most once a day, when the go command runs |
| Removes an entry | When it hasn't been used for five days |
| Removes fuzzing inputs | Never, by itself |
The comments in Go's code explain the five days: a month of statistics from Go developers found that nearly all reuse of a cache entry happened within five days of the last use.
Why can the build cache still be large?
Five days of work can be a lot. Go keeps separate entries for each Go version, each target platform and each set of build options, so a few days of switching between projects, Go releases or cross-compiling for Intel Macs and Linux fill it quickly.
Two other things keep it large. The trimming only happens when the go command runs, so a Mac where you stopped using Go months ago still has the cache as it was then. And fuzzing inputs are never trimmed, so a project you fuzz-tested for days keeps them until you remove them.
Is it safe to delete the Go build cache?
Yes. Everything in it is made by the go command from your code and your dependencies, and Go makes it again as you build and test. If the folder is missing, Go creates it again the next time it runs.
- Make sure nothing is building or testing, and quit editors with a Go project open.
- In Finder, choose Go › Go to Folder, type
~/and press Return.Library/ Caches - Move the go-build folder to the Trash.
- Empty the Trash when you're sure you don't need it back.
Move only the go-build folder, never the Caches folder itself, which every app on your Mac uses.
What does clearing the build cache cost?
The next build of each project compiles everything again, dependencies included, and every test runs again instead of reusing a passing result. For a large project that can take minutes.
Nothing is downloaded: the source code comes from the module cache, which clearing the build cache doesn't touch. If you'd fuzz-tested, the fuzzing inputs go too, so the next fuzzing run starts from your own test inputs.
Can you turn the build cache off?
No. Go has required the build cache since Go 1.12, and refuses to build with it turned off. You can move it: a Go setting points the build cache at another folder, such as one on a larger drive. Go's documentation also describes a way to hand the cache to a separate program that manages it.
The Go module cache
The module cache holds the source code of every module version your projects have used, shared by all of them. It's where Go looks first, so a module you've used once doesn't have to be downloaded again.
What's in the module cache?
Go's modules reference describes the layout. The parts that take space are:
- A folder for each module version, named after the module's path and version, holding its unpacked source code. Different versions of one module are separate folders.
cache/download, holding the zip file of each module version as Go downloaded it, plus small files describing it. So each module is stored twice: zipped and unpacked.cache/vcs, holding repositories Go cloned when it fetched a module straight from its source rather than through a proxy.golang.org/toolchain, the Go toolchains projects asked for, stored like any other module.
Is the module cache shared between projects?
Yes. Go's modules reference says the go command uses the same module cache wherever a project lives, and that several go commands can use it at once safely. A module version downloaded for one project is ready for every other project that needs it.
That's what makes it efficient, and also why it can't be cleared one project at a time: nothing in it says which project a module came from.
Why does the module cache only grow?
Go's modules reference is plain about it: the module cache has no maximum size, and the go command doesn't remove its contents automatically. Every dependency upgrade adds a new version folder next to the old one.
Projects you no longer work on keep their modules there too, since nothing records which project used which module. Over a few years of Go work, that adds up to many versions of the same modules.
Why can't you just move it to the Trash?
Go makes the module cache's files and folders read-only, so that nothing changes a module after it's downloaded. Go's documentation notes the side effect: the cache becomes hard to delete by ordinary means, and it points to its own clean command instead.
So there's no Finder route for the module cache that Go supports. Its clean command, with its module cache option, removes the whole folder, read-only files included. Like the rest of Go, it has no app or button.
What does clearing the module cache cost?
Each project downloads its modules again the next time it builds, by default from the Go module mirror at proxy.golang.org. That takes time and a network connection, and builds fail offline until the modules are back.
Nothing about your projects changes. Each project's go.sum file records a hash for every module it uses, and Go checks each downloaded module against it, so you get exactly the code you had. Modules from private repositories need your access to them again.
Is there a way to keep it deletable?
Go has a setting that leaves new folders in the module cache writable. Go's documentation warns about the cost: editors, tests and other programs could then change files in the cache by accident. It also applies only to modules downloaded after you turn it on.
Most people are better served by leaving the files read-only and clearing the cache with Go's own command when it's needed.
Toolchains in the module cache
Since Go 1.21, the go command can switch to a newer Go release when a project's go.mod asks for one. It downloads that release as a module, called golang.org/toolchain, into the module cache, and runs it from there.
Standard Go installations allow this by default. Each release downloaded this way is about 0.3 GB, as the chart above shows, and it stays until you clear the module cache. A Mac that works on projects pinned to several patch releases can collect several of them.
What go clean removes, option by option
Go's cleanup is one command, go clean, with an option for each cache. It has no app or button, and what it removes is deleted at once, not moved to the Trash. Go's documentation describes each option:
| How it's run | What it removes |
|---|---|
| With the cache option | The build cache's compiled packages and test results |
| With the test cache option | Nothing: it marks every saved test result as expired |
| With the module cache option | The whole module cache, including downloaded toolchains |
| With the fuzz cache option | The inputs saved while fuzzing, in the build cache's fuzz folder |
| With a package's name | Programs and leftover files that builds left in that package's folder |
| With the dry-run option | Nothing: it prints what it would remove |
Each option is separate. Clearing the build cache leaves the module cache alone, and the other way round.
What the cache option leaves behind
Go's code removes the 256 numbered folders and the cache's log, but not the build cache folder itself, and not the fuzz folder inside it. Fuzzing inputs have an option of their own.
Moving the whole go-build folder to the Trash in Finder frees everything the cache option does, plus the fuzzing inputs.
Why does the test cache option free nothing?
It doesn't delete test results. It writes a note in the build cache saying that every result saved before now has expired, so tests run again. It's for making tests run, not for freeing space; the expired results go when Go trims them five days later.
Which one to use when
- The disk is full and you need room now: the build cache. It costs only build time, and it can go to the Trash in Finder.
- You've used Go for years: the module cache. It holds every module version and toolchain you've ever downloaded.
- You fuzz-tested once and stopped: the fuzzing inputs.
- Tests seem stuck on an old result: the test cache option, which frees nothing but makes them run.
Other Go folders that take space
The two caches are where the space usually is, but a few other folders belong to Go too. Some of them are worth a look, and some should stay.
Programs you installed
Programs installed with Go's install command go into ~/, one file each. They're tools you chose to install, such as linters or code generators, not a cache.
Go's own uninstall instructions remove the whole folder when you're done with Go. If you're keeping Go, look through it in Finder and move a program you no longer use to the Trash; reinstalling it with Go brings it back.
The gopls cache
gopls, the Go language server that editors such as VS Code use for Go, keeps its own cache in ~/.
Its source code aims to keep it under about 1 GB and deletes files that haven't been used for five days. The code notes that the space it takes on disk can be up to three times that, because it's made of many small files.
It's one of the catalog's App caches in that folder, and gopls builds it again as you work. The golangci-lint linter keeps a cache of its own next to it, in ~/.
Extra Go versions in ~/sdk
Go's documentation describes a way to install several Go releases side by side, for testing code against more than one. Each release goes into its own folder in ~/, such as one named go1.26.9, with a small launcher program in ~/.
Go's instructions for removing one are to delete its folder and its launcher. Both are plain files you can move to the Trash in Finder. Each folder is a complete Go release, about the size of the installed one in the chart above.
Go itself
The installer from go.dev puts Go in /, and adds a file in / so your Mac can find it. Homebrew's go formula installs Go in Homebrew's own folder instead, where Homebrew upgrades and removes it.
Neither copy grows with use: the caches are elsewhere. Go's documentation explains how to remove each when you're done with Go, and the post on Homebrew's disk space covers Homebrew's side.
Go's settings file
Go keeps your own settings, such as a moved cache or a proxy, in a small file inside ~/. Go's documentation lists it with the folders to remove when you uninstall Go.
It takes almost no space. Leave it while you use Go: if a cache isn't where this post says, a setting in that file is a likely reason.
Old projects in ~/go/src
If you used Go before modules, your projects may live in ~/, where GOPATH mode expected them. That's source code, possibly your own, not a cache. Look through it before you remove anything, and move projects you want to keep somewhere you'll recognize.
Keeping Go's caches in check
The build cache looks after itself, and the module cache doesn't. Most of keeping Go's footprint small comes down to that difference.
The two caches side by side
| Build cache | Module cache | |
|---|---|---|
| Where | ~/Library/Caches/go-build | ~/go/pkg/mod |
| What it holds | Compiled packages, test results, cached programs | Module source code, zips and toolchains |
| Trimmed by Go | Yes, entries unused for five days | Never |
| Finder route | Move the folder to the Trash | None: its files are read-only |
| Cost of clearing | Full builds and test runs, once | Downloads, once per project |
| Setting that moves it | Go's build cache setting | Go's module cache setting, or GOPATH |
Clear the module cache after big upgrades
When you upgrade a project's dependencies or move it to a new Go release, the old versions stay in the module cache. Clearing it afterwards, then building the projects you still work on, leaves only what they use now.
It's the closest thing Go has to cleaning up one project's leftovers: everything goes, and the projects you care about bring back what they need.
Move the caches to another drive
Both caches can live elsewhere. Go's settings point the build cache and the module cache at any folder, such as one on a larger drive, and the build cache's setting must be a full path. Go reads these settings from its own configuration file or your shell's environment.
If you move them to an external drive, keep it connected while you work: Go needs its build cache to build anything.
Does clearing Go's caches make anything faster?
No. Clearing either cache frees space and nothing more. The next builds are slower, not faster, while Go fills the caches again. Go's documentation says the build cache accounts for changes to source files, compilers and their options, so clearing it shouldn't be needed in normal use.
The one exception it names is C code: the build cache doesn't notice changes to C libraries a package uses through cgo, so after updating those, clearing the build cache makes Go rebuild what depends on them.
Time Machine and Go's caches
Go doesn't mark its caches as excluded from backups, unlike Rust's Cargo, which marks its build folders itself. The post on Rust's target folders and Cargo caches explains how that works.
Should you exclude Go's caches from Time Machine?
If your backup disk is short of space, the module cache is a reasonable thing to leave out: everything in it can be downloaded again, and each module is checked against your projects' go.sum files when it is. The build cache is rebuilt from your code.
- Choose Apple menu › System Settings, click General, then click Time Machine.
- Click Options.
- Click the Add button and choose
~/, or drag the folder from a Finder window onto the list.go/ pkg/ mod - Click Done.
The build cache's folder is in your hidden Library folder. Open it with Go › Go to Folder, as above, and drag the go-build folder onto the list.
Do local snapshots still hold them?
Yes. Apple notes that excluded items still appear in Time Machine's local snapshots on your Mac. When you clear a cache, a snapshot can keep the old files for up to 24 hours, but macOS counts that space as available and removes snapshots sooner when it needs room.
What to clear first: a decision table
The right order depends on why you're looking. This table starts from the situation.
| Situation | What to clear | What it costs |
|---|---|---|
| The disk is nearly full | The build cache, in Finder | Full builds and test runs, once |
| Years of Go work | The module cache, with Go's clean command | Modules download again as projects need them |
| Many Go toolchains downloaded | The module cache, with Go's clean command | Toolchains download again if a project asks |
| You fuzz-tested and stopped | The fuzz folder in the build cache | Fuzzing starts from your own inputs again |
Old releases in ~/sdk | Their folders and launchers, in Finder | Installing them again if you need them |
| You're done with Go | Both caches, then Go itself, as Go's documentation describes | Installing Go again to build anything |
The build cache nearly always comes first, because it has a Finder route and costs only build time. The module cache comes next, when a network connection is handy.
What happens on the first build after clearing both?
Nothing you need to do, just a longer wait. In order:
- If the project's
go.modasks for a newer Go than yours, Go downloads that toolchain into the module cache first. - Go downloads each module the project needs and checks it against the project's
go.sumfile. - It compiles every package, the dependencies' and yours, and stores the results in the build cache.
- Tests run in full, since no earlier result is saved.
The second build is back to normal speed. Each other project you open goes through the same steps for whatever it needs that isn't cached yet.
When to leave the caches alone
Before a flight or anywhere without a reliable connection, keep the module cache: offline builds need it. And before a deadline, keep the build cache, so you don't wait for a full build at the wrong moment.
How often should you look?
Go trims the build cache by itself, so it rarely needs you. The module cache is worth a look every few months, or when System Data or Documents grows for no clear reason.
Mistakes to avoid
Go's folders look like ordinary folders in Finder, and most of the trouble comes from tidying the wrong one.
Don't move the whole go folder to the Trash
It holds programs you installed and, on older setups, your own code in its src folder, as well as the module cache. And the module cache's read-only files make the folder hard to remove that way. Clear the module cache with Go's command, and look through the rest yourself.
Don't delete vendor or testdata folders
Some projects keep copies of their dependencies in a vendor folder, and fuzz tests save failing inputs in testdata. Both are part of the project, often committed with it, not caches. Go's clean command doesn't touch testdata, and neither should you.
Don't change permissions to force the module cache out
Making the read-only files writable just to delete them is the workaround people pass around, and it's easy to point at the wrong folder. Go's own clean command does the same job safely and removes only the module cache.
Don't paste cleanup commands from a web page
Go's cleanup is a command, but a command copied from a web page can do more than it says. The quickest win here, clearing the build cache, works in Finder, with the Trash to fall back on.
Other languages keep caches like these too. The post on freeing disk space on a developer's Mac covers the rest of them, from Xcode to Docker.
How the app does it
Wombit finds Go's build cache and module cache, explains each one, and shows its size, with hard links and APFS clones counted once. Select either on the map to see what it is and what removing it costs.
Both are Safe: they start checked in Cleanup and count toward the safe total. After the review sheet, the app runs Go's own clean command for each instead of moving its files, as Go's documentation asks. What a command removes can't be put back, and the sheet says so.
What the app runs, after you review itPRO
- go clean -cache
- Go's build cache: compiled packages, test results and cached programs
- go clean -modcache
- Go's module cache: downloaded modules and Go toolchains
~/
Library/ Caches/ go-build Compiled packages and test results that the go command keeps so later builds and tests run faster.
Safe · Runs go clean -cache
~/
go/ pkg/ mod Source code of the Go modules your projects depend on, downloaded by the go command and shared between projects.
Safe · Runs go clean -modcache
Seeing all of this is free. Cleanup is PRO: one payment of $4.99 with lifetime access. Every Pro tool's review is free to open, so you see what would go and why before you buy.
Frequently asked questions
Is it safe to delete ~/Library/Caches/go-build?
Yes. It holds compiled packages, test results and cached programs that the go command makes again as you build and test, and Go creates the folder again if it's missing. Quit editors with a Go project open, then move the go-build folder to the Trash in Finder.
Why do I get permission errors when deleting ~/go/pkg/mod?
Go makes the module cache's files and folders read-only on purpose, so nothing changes a module after it's downloaded. Go's documentation says this makes the cache hard to delete by ordinary means, and points to its own clean command, which removes it read-only files and all.
What is the ~/go folder on my Mac?
It's Go's default GOPATH. It holds the module cache in pkg/mod, programs you installed with Go in bin, and, if you used Go before modules, older projects in src. Go creates it the first time it needs it.
Does go clean -cache delete downloaded modules?
No. It removes the build cache's compiled packages and test results, and leaves the module cache in ~/go/pkg/mod alone. Modules are removed only by Go's module cache option, and the fuzzing inputs by its fuzz cache option.
How big does the Go build cache get?
Go removes entries it hasn't used for five days, so the cache mostly reflects your last few days of work. Switching between Go versions, platforms and projects fills it faster. The research behind the app's catalog puts Go's two caches at 1 to 20 GB together.
Does Go delete old toolchains it downloaded?
No. Toolchains that Go downloads when a project asks for a newer release are stored in the module cache, which Go never trims. Each one is about 0.3 GB for Go 1.27 on Apple silicon, and they stay until the module cache is cleared.
Will clearing the Go module cache break my projects?
No. Each project downloads its modules again the next time it builds, and Go checks every download against the hashes in the project's go.sum file, so you get the same code. Builds need a network connection until the modules are back.