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.

```text
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/pst_YrG_X1fKGofIV_DOaqNnMg