osv-scanner: "failed to determine package versions for go.mod: no Go toolchain in PATH"

TL;DR: Install a Go toolchain at least as new as the go directive in go.mod, make sure the go command is on the PATH, and re-run the scanner. osv-scanner shells out to the go command to resolve module versions, so without it the Go packages cannot be evaluated. A working toolchain unblocks the scan.

failed to determine package versions for go.mod: no Go toolchain in PATH

1. Confirm the diagnosis. Run go version.

Expected: "command not found". If it prints a version, the toolchain exists but is not on the PATH the scanner sees, so fix the PATH instead.

2. Install Go. Use your platform's package manager or the official installer, choosing a release at least as new as the go directive at the top of go.mod.

Expected: the installer completes without errors.

3. Verify the toolchain is visible. Run go version again in the same shell or CI step that runs the scanner.

Expected: it prints a version number. The scanner runs in this same environment, so this check is representative.

4. Re-run osv-scanner against the go.mod.

Expected: the scanner resolves the module versions and reports findings instead of the toolchain error.

Use this when

• osv-scanner fails on a go.mod with the toolchain error
• the scan runs in a minimal container or CI image without Go
• go version works in your shell but the scanner step still fails (PATH scoping)

Not for this skill when

• the go command exists and the failure is about a specific module; that is a module resolution problem, not a toolchain problem
• the error names a different manifest (package-lock.json, Gemfile.lock); each ecosystem has its own prerequisites
• you are scanning an SBOM rather than a go.mod; the SBOM path does not shell out to go

Variant phrasings

osv-scanner needs go installed to scan go.mod

no Go toolchain in PATH osv-scanner

osv-scanner go.mod version resolution fails

install go for osv-scanner in CI

Why it happens

Go module version resolution is genuinely complex: replace directives, pseudo-versions, and toolchain-gated language versions all affect what "the version" of a dependency is. Rather than reimplement that logic, osv-scanner delegates to the real go command. No toolchain means no delegation, and the scanner fails the manifest instead of guessing versions.

Edge cases

• If go.mod demands a newer Go than you installed, the go command itself errors; match or exceed the go directive, and know that newer Go releases can auto-fetch toolchains when allowed.
• In CI, install Go in the same job and step environment as the scanner; a toolchain installed in an earlier container stage is not automatically on the later step's PATH.
• A go.work workspace changes which modules resolve; the scanner follows the workspace, so keep it in sync with what you build.
• Vendor directories do not remove the need for the toolchain here; version determination still goes through the go command.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstYrGX1fKGofIV_DOaqNnMg