TL;DR: Run osv-scanner from the repository root, or pass the lockfile paths explicitly. The scanner looks for package sources starting at the directory you give it, and a subdirectory with no lockfiles of its own yields nothing. Pointing it at the lockfiles directly fixes the scan.

```text
failed: no package sources found in .
```

1. Confirm where the lockfiles actually live. From the repo root, list lockfiles a couple of levels deep.
Expected: you see lockfiles (package-lock.json, Gemfile.lock, go.mod, requirements.txt, and friends) in the root or in subdirectories, but not in the directory where you ran the scanner.
2. Re-run from the repo root, or hand the scanner the lockfile directly with the lockfile flag pointed at the file's path.
Expected: the scanner reports the lockfiles it parsed instead of the no-sources error.
3. In a monorepo, pass each lockfile explicitly rather than hoping one invocation finds them all.
Expected: every package's dependencies get scanned, with findings attributed per lockfile.

## Use this when
- osv-scanner reports no package sources from a subdirectory
- CI runs the scanner with a working directory that is not the repo root
- the repo keeps lockfiles in nested package folders

## Not for this skill when
- the scanner finds lockfiles but reports no vulnerabilities; that is a clean result, not this error
- the lockfile itself fails to parse; that is a format problem with a different fix
- you are scanning a container image or SBOM; those use different input flags

## Variant phrasings
### osv-scanner no package sources found
### osv-scanner cannot find lockfile in subdirectory
### osv-scanner fails when run from nested folder
### how to point osv-scanner at a lockfile path

## Why it happens
osv-scanner discovers package sources by walking the directory you hand it, matching known lockfile names. Give it a directory whose walk finds no matches and it has nothing to query, so it fails loudly rather than silently reporting zero vulnerabilities. The error is the scanner refusing to pretend an empty scan is a clean scan.

## Edge cases
- A pnpm workspace with a pnpm-workspace.yaml but no pnpm-lock.yaml at the root still yields no sources at the root; point at the actual lockfiles.
- Some setups generate the lockfile during CI before the scan step; if the scan runs before generation, the directory is legitimately empty at scan time, so order the steps correctly.
- Symlinked monorepo layouts can confuse the directory walk; explicit lockfile paths are immune to that.
- The recursive walk can be slow on huge repos; explicit paths are faster as well as more predictable.

## Provenance

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