What does go:go_unrecognized_import_path mean?

Go could not discover the repository or module proxy that owns the requested import path. Check go-import metadata, module roots, and GOPROXY routing.

Which Go versions are affected by go:go_unrecognized_import_path?

Dynamic go-import discovery applies to modern Go releases. The optional fourth subdirectory field in go-import metadata requires Go 1.25 or later.

How can I manually validate go:go_unrecognized_import_path?

Run `go version` and `go env GOPROXY GOPRIVATE GONOPROXY` to confirm why this module is being resolved directly. From the failing environment, inspect `curl -fsSL "https:// ?go-get=1"` for a matching early `go-import` tag. Check whether the requested value is the true module root, a package below it, a typo, or a path that should include an explicit VCS suffix.

Go error: unrecognized import path and no go-import meta tags

Q: How do I prevent go:go_unrecognized_import_path in CI?

Test internal vanity paths from the DNS and network path used by CI. Document canonical module roots and supported Go versions. Keep private proxy policy consistent across developer and CI environments.

Fix it fast

Most likely: The module host is missing valid go-import metadata, or this request should have gone through the configured proxy.

Confirm this is your error

Match the output and confirm you are troubleshooting the same failure.

go: example.corp/team/lib@latest: unrecognized import path "example.corp/team/lib": parse https://example.corp/team/lib?go-get=1: no go-import meta tags ()
go: unrecognized import path "example.org/repo/pkg": fetching example.org/repo/pkg: no go-import meta tag found in https://example.org/repo/pkg?go-get=1

Check the cause

Run focused checks to identify what is failing in this environment.

go version
go env GOPROXY GOPRIVATE GONOPROXY
curl -fsSL "https://<module-path>?go-get=1"

Apply the safe fix

Use the smallest safe change that addresses the confirmed cause.

# After correcting discovery metadata or proxy selection
go list -m <module-path>@<version>

Verify it works

Repeat the relevant checks and confirm the original error is gone.

go list -m <module-path>@<version>
go build ./...

Avoid unsafe shortcuts

Keep security and data protections in place while troubleshooting.

Do not use GOINSECURE to compensate for missing discovery metadata.
Do not assume every package subdirectory is also a module root.

What This Error Means

Read this as a precise clue about which part of the workflow broke first. Once you know the failing layer, the fix path gets much shorter.

How to Fix It

The fastest fixes here come from checking the immediate failing layer before you change anything unrelated. Make one correction at a time and re-test from the same environment.

Vanity host:serve the correct go-import tag before scripts or styles and keep prefix responses consistent.

Wrong module root:use the module path declared by the dependency’s go.mod and keep package imports below it.

Private proxy path:correct GOPROXY and GONOPROXY so RepoFlow handles the module.

Direct private VCS:use a VCS suffix only when it is the documented module identity.

Client compatibility:avoid the optional subdirectory field for clients before Go 1.25, or update the supported toolchain.

Why It Happens

The vanity host returns normal application HTML but no go-import metadata.

The metadata prefix does not match the module or conflicts with its parent-prefix response.

The path is a package below the module root, or a private path bypassed RepoFlow.

The server uses the Go 1.25 subdirectory metadata form while the failing client is older.

Verify the Fix

Repeat go list -m <module-path>@<version> and confirm Go discovers the intended repository or proxy root.

Repeat the original build. Add -x only if more tracing is needed.

Inspect the path and its go-get discovery response

Run go version and go env GOPROXY GOPRIVATE GONOPROXY to confirm why this module is being resolved directly.

From the failing environment, inspect curl -fsSL "https://<module-path>?go-get=1" for a matching early go-import tag.

Check whether the requested value is the true module root, a package below it, a typo, or a path that should include an explicit VCS suffix.

How Go discovers an unfamiliar module host

This is the part worth understanding if the quick fix did not hold. It explains what Go is trying to do at the moment the error appears.

For an unfamiliar direct-fetch host without a VCS suffix, Go requests the path with ?go-get=1.

The HTML must contain a matching go-import tag for a VCS repository or module proxy. Missing, conflicting, or unsupported metadata stops discovery before Git authentication.

Prevent It From Coming Back

To prevent this, test internal vanity paths from the DNS and network path used by CI, document canonical module roots and supported Go versions, and keep private proxy policy consistent across developer and CI environments.

Docs and source code

Go repository discovery source

Current source for unrecognized import paths and go-import metadata discovery. - Source

Unknown hosts are queried for go-import metadata before Go chooses a repository root.

Go Modules Reference

Official reference for module files, version selection, proxies, private modules, checksums, workspaces, and vendoring. - Source

The go command uses module paths and versions to resolve, download, and authenticate dependencies.

go command documentation

Current command and environment-variable reference, including GOAUTH and module-aware commands. - Source

The go command provides module, workspace, environment, build, list, get, and install operations.