vale: error: no config file found: looked for .vale.ini in review

TL;DR

Vale looked for .vale.ini starting from the working directory and found nothing. Create a minimal .vale.ini at the repo root, or pass the real config path explicitly. The review step usually runs in a subdirectory, which is why it works on your machine and fails in CI.

The error

vale: error: no config file found: looked for .vale.ini in review

Steps

1. Confirm where vale is running

Check the review workflow's working directory and where the config file actually lives. Expected output: the config is at the repo root but vale runs in a subdirectory, or no config exists at all.

2. Create a minimal .vale.ini at the repo root

Write this:

StylesPath = styles
MinAlertLevel = warning
[*.md]
BasedOnStyles = write-good

Expected output: the file exists at the repo root.

3. Add the styles directory

Create the styles directory and either install the referenced style package or drop the BasedOnStyles line and write your own rules. Expected output: vale --config=.vale.ini README.md runs without the config error.

4. Point the review step at the config

If the workflow must run in a subdirectory, pass the config path explicitly to the vale or reviewdog invocation. Expected output: the review step finds the config regardless of working directory.

5. Pin the vale version

Lock the vale version in the workflow so a future release with different config lookup does not surprise you. Expected output: repeatable review runs.

When to use

• vale fails with no config file found during PR review
• A fresh vale setup that works locally but not in CI
• Monorepo PRs where the review step runs in a subdirectory

When not to use

• Style-rule violations (the config is fine; the prose is not)
• Missing style packages (install the package instead)
• Debates about which prose rules the team wants

Tool compatibility

• vale v2/v3; the .vale.ini lookup behavior is the same across recent versions
• reviewdog's vale support passes a config path through
• Works on GitHub Actions, GitLab CI, and pre-commit hooks

Variant phrasings

vale.ini vs .vale.ini lookup order

Vale checks .vale.ini then vale.ini then _vale.ini, walking up from the working directory. Any of them works; pick one and be consistent.

reviewdog vale config not found

Pass the config path in the reviewdog action inputs instead of relying on working-directory lookup.

vale works locally but fails in CI

Almost always a working-directory mismatch. Print the working directory in the workflow to confirm, then use step 4.

Why it happens

Vale resolves its config relative to where it is invoked, walking upward. Locally you run it from the repo root, so it finds the file. In CI the review step often sets a different working directory or checks out a subdirectory, so the upward walk never reaches the config.

Edge cases

• Monorepos with per-package prose rules: keep one root config and add per-directory overrides in [path] sections.
• Vale run against files outside the repo: config lookup still starts from the invocation directory, so pass the path explicitly.
• Case-sensitive filesystems: .Vale.ini is not .vale.ini. Match the exact lowercase name.

Provenance

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