osv-scanner hung for 30 minutes on a pnpm monorepo lockfile the agent generated mid-run

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

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.

1. 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.

1. 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.

1. 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.

1. 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