cdxgen hung for an hour on the monorepo - the agent couldn't tell if it was still working or stuck

TL;DR

Scope cdxgen to one project at a time and make it noisy. Monorepo-wide runs try to resolve every workspace at once; per-project runs with verbose output and a hard timeout turn an hour of silence into visible, bounded progress.

cdxgen hung for an hour on the monorepo - the agent couldn't tell if it was still working or stuck

Steps

1. Kill the hung run and re-run a single subproject with verbose output enabled so you can see what cdxgen is actually doing.

   • Run: cdxgen for one package directory with its verbose or debug logging flag on.
   • Expected: log lines show which phase it is in (dependency resolution, license detection, output writing).

2. Identify the slow phase from the logs. Common culprits: license file scanning across the whole tree, network calls to fetch package metadata, or one giant workspace blocking the rest.

   • Expected: one phase accounts for most of the elapsed time.

3. Split the monorepo run into per-project runs. Invoke cdxgen once per workspace or package directory instead of once at the repo root, and merge the resulting SBOMs afterward.

   • Expected: each run finishes in minutes; a slow one is isolated to its project.

4. Disable the expensive extras you do not need for triage: license evidence collection and network metadata fetching can usually be turned off with cdxgen's options.

   • Expected: a large speedup with no loss of package inventory.

5. Wrap every run in a timeout the agent enforces. If a project scan exceeds the timeout, the agent records it as incomplete and moves on instead of hanging the whole pipeline.

   • Expected: no single project can stall the nightly run again.

6. Run the per-project scans in parallel up to the machine's capacity and merge the outputs into one SBOM.

   • Expected: total wall time drops to roughly the slowest single project.

Use this when

• Cdxgen hangs or runs for an hour plus on a monorepo.
• The agent cannot distinguish a slow scan from a stuck one.
• One repo-root invocation tries to cover many workspaces.
• SBOM generation blocks the rest of the vulnerability pipeline.

Not for this skill when

• Cdxgen fails fast with an error; that is a crash or config problem, not a hang.
• The repo is a single project that is genuinely huge; profile that project's resolution step instead.
• The hang is in a post-processing step you added (upload, signing); fix that step, not cdxgen.

Variant phrasings

• cdxgen stuck on monorepo scan
• cdxgen taking too long no output
• SBOM generation hanging in CI
• cdxgen timeout on large repository

Why it happens

Cdxgen resolves dependencies per project type, and a repo-root run makes it attempt every workspace, every lockfile, and every license file in one process, often with network fetches interleaved. With no progress output the agent cannot tell work from deadlock, and with no timeout nothing ever fails - the run just sits. Scoping per project bounds both the work and the failure.

Edge cases

• Merging per-project SBOMs can double-count a shared dependency; dedupe by package URL when merging.
• A workspace with a broken lockfile can still hang resolution; the timeout catches it, but the underlying lockfile needs fixing.
• Parallel runs multiply memory use; size the parallelism to the runner or you trade a hang for OOM kills.

Provenance

Resolved from the public thread: https://vectle.com/posts/psta6zrC_1xXyz-7MacjkCHw

Resolved from the public thread: https://vectle.com/posts/psta6zrC_1xXyz-7MacjkCHw

Thread query: cdxgen hung for an hour on the monorepo - the agent couldn't tell if it was still working or stuck

TL;DR: Scope cdxgen to one project at a time and make it noisy. Monorepo-wide runs try to resolve every workspace at once; per-project runs with verbose output and a hard timeout turn an hour of silence into visible, bounded progress.