Excluding paths from a scan

secfoo tells the agent CLI what's out of scope before it starts reading files, rather than filtering findings after the fact — the agent never spends a tool call opening a path it's been told to skip.

What's already excluded, always

Every run excludes a fixed list of build artifacts, dependency directories, and caches — these are never security-relevant and there's no flag to re-enable them:

node_modules/  .git/  dist/  build/  out/  .next/  .nuxt/
venv/  .venv/  env/  __pycache__/  .pytest_cache/  .mypy_cache/
.ruff_cache/  coverage/  .turbo/  target/  vendor/  .terraform/
*.min.js  *.min.css  *.egg-info/  *.lock

Adding your own

Everything you add on top is additive, never a replacement for the built-in list — excluding a vendored directory doesn't silently turn scanning of node_modules/ back on. For a single run:

secfoo run --skill sast --agent claude \
  --exclude legacy-billing/ --exclude "*.generated.ts"

--exclude is repeatable. Set it once for every future run instead, in ~/.secfoo/config.toml:

[defaults]
exclude = ["vendor/", "third_party/", "some-cloned-repo/"]

A CLI --exclude flag adds to the config's list rather than overriding it — naming one path on the command line can't silently drop the others you already configured.

Built-in vs. your own: not quite the same instruction

The two lists read differently to the agent, on purpose:

Built-in excludes"Build artifact or cache, never security-relevant" — the agent skips them as noise, full stop.

Your --exclude paths"Not part of the system under review" — a vendored copy, an unrelated checked-out repo, a test fixture. The agent doesn't read them, doesn't report findings in them, and doesn't count them toward coverage/inventory at all.

That distinction matters for a skill like Security Architecture Review, which reports on how much of a system it actually covered — a build artifact being skipped shouldn't read as a coverage gap, but a whole sibling repo you explicitly excluded shouldn't be silently counted as "reviewed" either.

When you'd actually need this

A monorepo where only one package is in scope for this particular assessment.
A checked-out reference implementation or unrelated cloned repo sitting alongside your real project (secfoo can't tell it apart from the target on its own).
Generated code you don't want findings raised against (migrations, generated API clients, etc.) — though for anything you actually ship, consider whether it should be in scope rather than excluded.

See secfoo run in the CLI reference for the full flag, and the Configuration page for [defaults].