CI is the final check. If dead code slips through agent workflows or editor review, CI catches it before it lands in main.
GitHub Action
Manual Setup
Other CI
Add the action
Add fallow to your workflow file: name : Dead code analysis on : [ push , pull_request ] jobs : fallow : runs-on : ubuntu-latest steps : - uses : actions/checkout@v4 - uses : fallow-rs/fallow@v0 with : format : sarif
Configure inputs
Customize the action with these inputs: Input Default Description commandcheckCommand to run (check, dupes, fix) formatsarifOutput format productionfalseEnable production mode changed-since— Only check files changed since this ref baselinefalseCompare against saved baseline
Upload SARIF (optional)
Upload results to GitHub Code Scanning for inline annotations on the PR diff: - uses : fallow-rs/fallow@v0 with : format : sarif - uses : github/codeql-action/upload-sarif@v3 with : sarif_file : results.sarif
GitHub Actions job summary
fallow check — 3 issues found | Type | File | Symbol | Line | | ------ | ------ | -------- | ------ | | unused-export | src/utils/format.ts | formatCurrency | 12 | | unused-export | src/utils/format.ts | formatPercentage | 28 | | unused-file | src/legacy/oldApi.ts | — | — | Completed in 22ms
SARIF upload to GitHub Code Scanning shows dead code issues as inline annotations directly on the PR diff.
If you prefer not to use the action, run fallow directly: - run : npx fallow check --format sarif > results.sarif
Or with specific checks: - run : npx fallow check --fail-on-issues --format compact
Duplication checks - run : npx fallow dupes --threshold 5 --format compact
This fails if the overall duplication percentage exceeds 5%. Fallow works in any CI environment that can run Node.js or download a binary. The basic pattern is the same: # Run with npx (no install needed) npx fallow check --format compact # Or download the binary directly curl -fsSL https://get.fallow.dev | sh fallow check --format compact
Exit codes Code Meaning 0No error-severity issues found 1Error-severity issues found 2Fatal error (invalid config, parse failure)
For pull requests, use --changed-since to only check files modified in the PR. This keeps CI fast and focuses feedback on new code.
PR-only analysis - uses : fallow-rs/fallow@v0 with : changed-since : ${{ github.event.pull_request.base.sha }}
Incremental adoption with baselines
Adopting fallow on a large codebase? Use baselines to avoid blocking on pre-existing issues while catching new ones. 1. Save a baseline on your main branch: npx fallow check --save-baseline git add .fallow-baseline.json && git commit -m "chore: add fallow baseline"
2. In your PR workflow, compare against the baseline: - run : npx fallow check --baseline
Only issues not present in the baseline will be reported. As your team cleans up existing dead code, periodically regenerate the baseline on main. Baselines must be committed to your repo. Don’t regenerate on every CI run. That defeats the purpose of incremental adoption.
The three tracks together CI is most powerful when combined with agent and editor integration:
Agent generates code and runs fallow check --changed-since HEAD~1 to self-checkHuman reviews in VS Code, sees Code Lens annotations on new exportsCI runs the full analysis. If something slipped through, CI catches it
The sub-second speed means fallow adds negligible time to your pipeline, even on large monorepos.
See also
Agent integration How AI agents use fallow via CLI and MCP.
Rule configuration Configure severity levels and issue types.
Production mode Exclude test and dev files from analysis.
