How to Remove Packages Installed with go get in Go

By the end of this page, you will understand what go get used to install, where Go stores downloaded source code and compiled binaries, and how to safely remove packages from your Go workspace. You will also learn the difference between removing source code, cached modules, and installed executables, plus how this differs between older GOPATH workflows and modern Go modules.

In Go, go get has historically been used to download and install packages. The important part is that Go does not usually install third-party code into the Go compiler itself. Instead, it places files in specific workspace locations.

The exact behavior depends on which Go workflow you are using:

• Older GOPATH mode: packages are downloaded into your GOPATH/src, compiled package files may appear under GOPATH/pkg, and executables may be placed in GOPATH/bin.
• Modern module mode: dependencies are usually stored in the module cache, typically under GOPATH/pkg/mod, and command-line tools may still install binaries into GOPATH/bin or GOBIN.

This matters because removing a package means removing it from the correct location:

• Remove the source or module files if you no longer want the downloaded package.
• Remove the binary executable if go get or go install installed a command.
• Sometimes you may also want to clean Go's build or module cache.

A common beginner misunderstanding is thinking that go get modifies the core Go installation under GOROOT. Normally, third-party packages belong in your workspace or module cache, not in the standard library directory.

So the real question is not "How do I uninstall Go itself?" but rather "Which Go-managed files did this package create, and which of those do I want to remove?"

Think of Go's package system like a workshop with separate storage areas:

• GOROOT is the factory equipment. You usually do not touch it.
• GOPATH/src or the module cache is the storage shelf for downloaded parts.
• GOPATH/bin is the tool rack where runnable tools are placed.
• pkg and cache folders are the temporary workbench outputs.

If you downloaded the wrong tool, you do not throw away the whole workshop. You remove:

• the stored parts,
• the built tool,
• and maybe the temporary scraps.

That is how removing packages installed by go get works in practice.

Check your Go paths

Before deleting anything, inspect where Go is storing files:

go env GOPATH
go env GOROOT
go env GOBIN

This helps you avoid deleting files from the wrong place.

Typical old GOPATH locations

If you ran:

go get github.com/user/tool

Go may have created files in these locations:

$GOPATH/src/github.com/user/tool
$GOPATH/pkg/...               # compiled package files
$GOPATH/bin/tool              # executable, if the package builds a command

To remove them manually:

rm -rf "$GOPATH/src/github.com/user/tool"
rm -f "$GOPATH/bin/tool"

You can also clear compiled package data with:

go clean -i github.com/user/tool

Modern module-related cleanup

If the package was downloaded into the module cache, you can clean unused downloaded modules with:

go clean -modcache

Be careful: this removes the entire module cache, not just one package.

Removing a tool installed as a binary

If you installed a command-line program, the most important thing to delete is often the binary:

rm -f "$(go env GOPATH)/bin/tool"

If GOBIN is set, check there instead:

go env GOBIN

Example

Suppose you ran:

go get github.com/rakyll/hey

Now you want to remove it.

Step 1: Find your workspace

Run:

go env GOPATH

Assume it returns:

/home/alex/go

Step 2: Check whether a binary was installed

Look in:

/home/alex/go/bin

If you see a file named hey, remove it:

rm -f /home/alex/go/bin/hey

Step 3: Remove the downloaded source or package files

In older GOPATH mode, the source code may be here:

/home/alex/go/src/github.com/rakyll/hey

Remove it:

rm -rf /home/alex/go/src/github.com/rakyll/hey

Step 4: Remove compiled artifacts if needed

Run:

go clean -i github.com/rakyll/hey

This removes installed archive or object files associated with that package in older workflows.

Step 5: Verify

Check that the binary is gone:

ls /home/alex/go/bin

And confirm the source directory no longer exists:

ls /home/alex/go/src/github.com/rakyll

If the folder is gone or the package directory is missing, the package has been removed.

What actually happened?

• The executable was removed from bin.
• The downloaded package source was removed from src.
• Optional compiled artifacts were cleaned.

Your Go installation itself was not modified; only your workspace contents were changed.

Developers remove Go packages for several practical reasons:

• Cleaning a mistaken install: you installed a package before setting GOPATH or GOBIN correctly.
• Removing old CLI tools: a tool was installed globally and you no longer use it.
• Resetting a broken environment: cached modules or compiled artifacts are causing confusing behavior.
• Keeping development environments reproducible: you want dependencies defined in go.mod, not installed ad hoc.
• Freeing disk space: the module cache can become large over time.

Examples:

• A developer accidentally installs a CLI tool into the default workspace and wants it removed.
• A CI machine needs a clean module cache before rebuilding dependencies.
• A team standardizes on go install module@version and removes older binaries installed with go get.
• A local machine has stale package data after switching Go versions.

In real Go projects, developers usually avoid manually installing library dependencies globally. Instead, they use these patterns:

Module-managed dependencies

Inside a project with go.mod, dependencies are tracked in files rather than manually managed in GOPATH:

go mod tidy

This removes unused dependencies from go.mod and go.sum, though it does not directly delete all cached module files.

Installing tools explicitly

Modern Go commonly uses:

go install example.com/cmd/tool@latest

This makes it clearer that you are installing a binary tool, not adding a library dependency to a project.

Environment inspection and guard checks

Developers often verify paths before deleting anything:

go env GOPATH GOBIN GOROOT

This acts like a guard clause for shell operations: check first, then delete.

Cleaning caches during troubleshooting

Common cleanup commands include:

go clean -cache
go clean -modcache
go clean -testcache

These are often used when builds behave unexpectedly.

Avoiding direct edits in shared folders

In real codebases, developers rarely edit or delete package directories blindly. They:

• inspect the environment,
• confirm whether a package is a library or executable,
• remove only the relevant binary or cache,
• let go.mod control project dependencies.

1. Confusing GOROOT with GOPATH

A very common mistake is assuming third-party packages are installed into the Go standard library.

• GOROOT = where Go itself is installed
• GOPATH = your workspace for user-downloaded packages in older workflows

Do not delete random directories from GOROOT unless you are intentionally uninstalling or repairing Go itself.

2. Deleting the wrong thing

Broken approach:

rm -rf /usr/local/go

This removes the Go installation, not just one downloaded package.

Safer approach:

go env GOPATH
rm -rf "$GOPATH/src/github.com/user/package"

3. Forgetting about binaries

A package may be gone from source storage, but its executable may still remain in bin.

Example:

rm -rf "$GOPATH/src/github.com/user/tool"

If tool still exists in $GOPATH/bin, you can still run it.

4. Using go clean -modcache for a single package

This command removes the entire module cache:

go clean -modcache

That is sometimes useful, but it is much broader than removing one package.

5. Expecting dependency removal to work like package managers

Go does not behave like apt, npm uninstall, or pip uninstall for all historical workflows. In many cases, cleanup is just file removal from known locations.

6. Not checking GOBIN

If GOBIN is set, executables may not be in $GOPATH/bin.

Check with:

go env GOBIN

7. Assuming go get behaves the same in every Go version

The role of go get changed over time. In modern Go:

• dependencies are usually managed with modules
• tool installation is commonly done with go install module@version

So always consider your Go version and workflow before cleaning files.

Related cleanup targets

GOPATH mode vs module mode

go get vs go install

Remove source vs remove binary

Quick reference

Check paths

go env GOPATH GOROOT GOBIN

Old GOPATH cleanup

Remove downloaded source:

rm -rf "$GOPATH/src/github.com/user/package"

Remove installed binary:

rm -f "$GOPATH/bin/package"

Remove compiled artifacts:

go clean -i github.com/user/package

Module/cache cleanup

Remove build cache:

go clean -cache

Remove test cache:

go clean -testcache

Remove module cache:

go clean -modcache

Important rules

• Third-party packages are usually not part of GOROOT.
• GOPATH is the main place to inspect in older setups.
• GOBIN may override where executables are installed.
• go clean -modcache removes all cached modules.
• In modern Go, use go install module@version for tools.

Safe order of operations

1. Run go env
2. Find the package or tool location
3. Delete the binary if needed
4. Delete source or module files if needed
5. Clean caches only if necessary

How do I uninstall a Go package installed with go get?

Usually by deleting the downloaded package directory from your workspace and removing any installed binary from GOPATH/bin or GOBIN.

Does go get install packages into GOROOT?

Normally, no. Third-party packages are typically stored in GOPATH or the module cache, not inside the core Go installation.

How do I remove an installed Go command-line tool?

Delete its executable from $(go env GOPATH)/bin or from GOBIN if that variable is set.

What does go clean -modcache do?

It removes the entire downloaded module cache. Use it when you want a full dependency cache reset, not just one package removed.

What is the difference between removing a package and removing a binary?

Removing a package deletes source or cached dependency files. Removing a binary deletes the runnable executable. Sometimes you need to do both.

Should I delete files from GOROOT to clean up third-party packages?

No. Deleting files from GOROOT can damage your Go installation. Check GOPATH and GOBIN first.

How do I clean unused dependencies in a modern Go project?

Run go mod tidy inside the project. This updates module dependency files, though it does not necessarily remove every cached module file on disk.

GOPATH

The older Go workspace system. It determines where source code, packages, and binaries are stored.

GOROOT

The location of the Go installation itself. It helps clarify what should usually not be deleted.

Go modules

The modern dependency management system in Go. It changes how packages are downloaded and tracked.

go install

The preferred modern command for installing Go tools as executables.

go clean

Used to remove build artifacts, caches, and some installed package data.

go mod tidy

Helps remove unused module requirements from a project's dependency files.

GOBIN

Controls where Go installs executable binaries, which matters when removing installed tools.