Go “Package Not Found” After go mod tidy

Running go mod tidy is supposed to clean up your dependencies, but it can sometimes leave you with a “package not found” error for something that was working fine a moment ago. This usually means Go couldn’t resolve or verify a module it needed, and it’s more often a configuration issue than a genuinely missing package.

The Problem

After running go mod tidy, building or running your project fails with something like:

go: github.com/yourorg/private-repo@v1.2.0: reading github.com/yourorg/private-repo/go.mod at revision v1.2.0: unknown revision v1.2.0
go build example.com/yourapp: package example.com/yourapp/internal/utils is not in std

The package might genuinely exist, be correctly imported, and even build fine on another machine — which points toward an environment or resolution issue rather than a real missing file.

Why It Happens

The most common causes of this error after go mod tidy fall into a few categories:

• The module is a private repository, and Go’s module proxy (proxy.golang.org by default) can’t access it, since it isn’t publicly available for the proxy to fetch and verify
• An internal package’s import path doesn’t match your module’s declared path in go.mod, often after renaming a folder, moving files around, or copying code between projects without updating the module path
• The local module cache has a stale or corrupted entry for a dependency, especially after force-pushing over a tag or otherwise changing a version’s content after it was already fetched once
• A typo in an import path that go mod tidy tried to resolve as a real external module, rather than the internal package it was actually meant to reference

The Fix

First, check whether the problematic package is a private repository. If so, tell Go not to route it through the public proxy or checksum database:

go env -w GOPRIVATE=github.com/yourorg/*

Make sure your Git credentials are also configured to access that private repo over HTTPS or SSH, since Go will fall back to a direct git fetch for anything matching GOPRIVATE, and that fetch still needs valid authentication:

git config --global url."git@github.com:".insteadOf "https://github.com/"

If the issue is an internal package path mismatch, confirm the module path declared at the top of go.mod matches how you’re importing internal packages throughout your code:

module example.com/yourapp

// then internally:
import "example.com/yourapp/internal/utils"

If these don’t match exactly (including capitalization), Go won’t resolve the internal import correctly, and go mod tidy may try (and fail) to treat it as an external dependency instead.

If you suspect a stale or corrupted module cache, clear it and let Go re-fetch everything from scratch:

go clean -modcache
go mod tidy

Still Not Working?

If none of the above resolves it, run go mod tidy with verbose output to see exactly what Go is trying to fetch and where it’s failing in the resolution process, which is often more informative than the final error alone:

go mod tidy -v

If you’re working behind a corporate proxy or VPN that blocks direct access to proxy.golang.org, also confirm whether GOPROXY is set to something reachable from your network, since an unreachable proxy produces errors that look identical to a genuinely missing package:

go env GOPROXY

If it’s set to the default and your network blocks it, either point it at an internal proxy your organization runs, or fall back to fetching directly from version control for the affected modules:

go env -w GOPROXY=direct

It’s also worth checking whether your go.sum file has become inconsistent with go.mod, which can happen after manually editing either file, or after merging a branch that changed dependencies without regenerating both files together. Deleting go.sum and letting Go regenerate it from scratch, alongside a fresh go mod tidy, resolves this category of issue in most cases:

rm go.sum
go mod tidy

Finally, if the project is part of a larger monorepo with multiple Go modules, confirm you’re running the command from the correct module root. Running go mod tidy from a subdirectory that isn’t itself a module root, or that has its own separate go.mod with different requirements than you expect, produces confusing errors that look like missing packages but are really just a mismatch between which module’s dependency graph is actually being resolved.