biome ci: The Read-Only Command for Pipelines
biome ci runs the same format, lint, and import checks as check but is hard-wired to never modify files.
ci exists precisely so a pipeline cannot accidentally apply fixes. It is the recommended command to run in continuous integration.
What it does
biome ci runs the formatter, linter, and import sorting in report-only mode. It never accepts a write flag, so it is safe to run in an environment where you only want verification. It exits non-zero if any error-level diagnostic is found.
Common usage
npx @biomejs/biome ci ./src
npx @biomejs/biome ci .
# annotate a pull request in GitHub Actions
npx @biomejs/biome ci --reporter=github ./srcOptions
| Flag | What it does |
|---|---|
| <paths> | Files or directories to verify |
| --reporter=github | Emit GitHub Actions workflow annotations |
| --reporter=junit | Emit JUnit XML for test report tooling |
| --error-on-warnings | Exit non-zero on warnings, not only errors |
| --changed | Only process files changed against the VCS base (needs vcs config) |
| --max-diagnostics=<n> | Cap the number of printed diagnostics |
In CI
Prefer ci over check in pipelines. It cannot be told to write, so there is no risk of a fix leaking into the run, and --reporter=github turns each diagnostic into an inline annotation on the PR.
Common errors in CI
ci exits 1 on the first error-level diagnostic batch and the job fails. "Unknown command write" style errors mean someone passed a write flag, which ci rejects by design; use check for that. If --changed reports nothing changed, the vcs section in biome.json is missing or useEnabled/defaultBranch is not set.