semgrep scan timed out when agent tried to review the monorepo PR

TL;DR

Stop scanning the whole monorepo on every PR: limit the run to changed files plus a focused ruleset, exclude generated and vendored directories, and add parallel jobs. That combination usually takes a timing-out scan down to minutes. Raising the CI timeout is the last resort, not the fix.

The error

$ semgrep scan --config=auto --baseline-ref=main
...
Error: scan exceeded the job time limit (20m) - timed out

Fix it

1. Prove scope is the problem. List the changed files with git diff --name-only main...HEAD, then run semgrep on just those files with your normal config. Expected: the scan finishes in seconds or minutes - confirming the full-repo scope, not the rules, was the bottleneck.

2. Exclude the noise permanently. Add excludes for vendored and generated paths to the CI invocation, for example --exclude=vendor --exclude=node_modules --exclude=*.min.js --exclude=*.lock. Expected: a sharp drop in scan time on the next run.

3. Trim the ruleset for the PR gate. Run a high-signal ruleset (for example p/security-audit) on PRs and move the full registry scan to a nightly job. Expected: fewer rules evaluated per file, faster gate, and the nightly run still catches the rest.

4. Parallelize. Add -j 4 (or match your runner's core count) to the scan command. Expected: near-linear speedup up to the available cores.

5. Only now, if it still does not fit, raise the CI job timeout - and set a per-rule --timeout so one pathological rule cannot eat the whole budget. Expected: the job completes inside the new limit with the slowest rules identified in the timing output.

Use this when

• The semgrep job times out on monorepo PRs and blocks review
• You see "scan timed out" or the job killed for exceeding its time limit
• A review is stuck waiting on semgrep while the diff itself is small

Not for this skill when

• Semgrep fails fast with a rule syntax error - fix the rule YAML, this is not a performance problem
• One single file hangs the scan - profile that file and rule instead of rescoping everything
• Results are empty because the config does not cover the repo's languages - a config problem, not a timeout

Variant phrasings

• semgrep scan timed out
• semgrep slow monorepo
• semgrep timeout config
• semgrep CI job too slow

Why it happens

--config=auto runs hundreds of rules over every file git tracks, including vendored code, generated files, and lockfiles. On a monorepo that is hours of rule evaluation per run. A PR review only needs two things: the changed files, and the rules most likely to catch real issues in them.

Edge cases

• --baseline-ref suppresses old findings but still scans everything - pair it with include and exclude filters
• Exclude lockfiles and generated code from the PR gate explicitly, or they dominate scan time
• Semgrep skips files over its max-bytes limit silently - know what is being skipped so a huge generated file does not hide real code
• Keep the nightly full-repo scan, or the PR gate's narrow scope becomes a blind spot over time

Provenance

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

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

Thread query: semgrep scan timed out when agent tried to review the monorepo PR

TL;DR: Stop scanning the whole monorepo on every PR: limit the run to changed files plus a focused ruleset, exclude generated and vendored directories, and add parallel jobs. That combination usually takes a timing-out scan down to minutes. Raising the CI timeout is the last resort, not the fix.