# osv-scanner hangs on a pnpm monorepo lockfile

## TL;DR

Kill the hung scan and do not scan the lockfile until the pnpm install that created it has fully finished. The agent scanned a half-written pnpm-lock.yaml, and osv-scanner's pnpm parser chews on the incomplete importers section instead of erroring out. Finish the install, verify the lockfile is stable, then re-scan. The same file scans in seconds once it is whole.

## The failure

```text
osv-scanner hung for 30 minutes on pnpm-lock.yaml with no output and no progress
(lockfile was generated by a pnpm install still running in the background)
```

## Steps

1. Stop the hung scan and check whether a pnpm install is still running: run `ps aux` and look for a pnpm process, or check whether pnpm-lock.yaml has been modified in the last few minutes. Expected: you find the install still running, or the lockfile timestamp keeps changing.

2. Let the install finish (or kill it and rerun it cleanly), then confirm the lockfile is stable: check its modification time twice, 30 seconds apart. Expected: identical timestamps, meaning nothing is still writing to it.

3. Validate the lockfile parses before scanning: run `pnpm install --frozen-lockfile --prefer-offline` in the workspace root. Expected: it exits 0 without changing the lockfile, which proves the file is complete and consistent.

4. Re-run the scan with a hard timeout: run `timeout 600 osv-scanner --lockfile mount the host path pnpm-lock.yaml at container path /`. Expected: the scan completes well inside the timeout, or the timeout kills it with a clear signal instead of a silent hang.

5. If the full monorepo scan is still slow, shard it: run osv-scanner per workspace package directory instead of the whole repo at once. Expected: each shard finishes in minutes and results merge cleanly.

## Use this when

- osv-scanner stalls with no output on a pnpm lockfile
- the lockfile was generated by an install the agent ran moments before the scan
- a monorepo scan that used to take minutes suddenly never finishes
- the agent runs install and scan as overlapping steps in one workflow

## Not for this skill when

- osv-scanner errors immediately with a parse error (that is a malformed lockfile, scan a fixed one)
- the hang is on npm, yarn, or Go lockfiles (different parsers, different fixes)
- the scan is slow but making progress (tune with sharding, not this fix)
- osv-scanner hangs on an SBOM input rather than a lockfile

## Variant phrasings

- osv-scanner stuck scanning pnpm-lock.yaml forever
- osv-scanner never finishes on a pnpm workspace
- osv scanner hangs with no error on monorepo lockfile

## Why it happens

pnpm writes pnpm-lock.yaml incrementally during install, and the file is not valid until the install completes. The agent kicked off the scan while the install was still writing, so osv-scanner's pnpm parser hit a structurally incomplete importers section and spun instead of failing. Scanners assume lockfiles are static artifacts. Scanning a file that is still being written breaks that assumption, and the hang is the parser's way of never finding the end of what it is reading.

## Edge cases

- A crashed install can leave a stale but complete-looking lockfile. If step 3 fails, delete the lockfile and regenerate with a fresh `pnpm install`.
- `timeout` kills the scan but not the underlying cause. If hangs recur, gate the scan step on install completion in your pipeline.
- pnpm v9 lockfiles have a different structure than v6. If you recently upgraded pnpm, make sure your osv-scanner version supports the new format.
- Sharded scans can double-count shared workspace deps. Dedupe results on package name plus version when merging.

## Provenance

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