Include and exclude rules
Narrow what gets indexed with .quarryignore files or config-level rules, gitignore-style.
By default Quarry indexes every text-extractable file under a watched folder. Most folders have things you do not want in the index: build output, dependency directories, drafts. Two mechanisms narrow that down, and they can be used together.
.quarryignore files
Place a file named .quarryignore next to the content it applies to. The syntax matches
.gitignore: one pattern per line, # starts a comment, and a leading ! re-includes a
path an earlier pattern excluded.
# build output
dist/
node_modules/
# temp files
*.tmp
*.swp
# but keep this one build artifact
!dist/manifest.jsonQuarry reads .quarryignore files at index time and again whenever the daemon detects a
change to one. A pattern applies to the directory the file lives in and everything below it,
the same scoping rules as git.
Pattern syntax
| Pattern | Matches |
|---|---|
*.log |
Any file ending in .log, at any depth. |
build/ |
A directory named build, and everything under it. |
/README.md |
Only README.md at the root of this .quarryignore file’s directory. |
drafts/** |
Everything under drafts/, including nested directories. |
!keep.log |
Re-includes keep.log even if an earlier pattern excluded it. |
Order matters. Later lines can override earlier ones, but only within the same file; a
pattern in a parent directory’s .quarryignore cannot be un-excluded by a child directory’s
file unless the child repeats the negation.
Config-level rules
The same effect can be set in the settings file, under
[index.<name>]. This is useful when you do not want to add a file to the folder itself, or
when you are scripting index setup.
[index.notes]
path = "/Users/dana/notes"
exclude = ["*.tmp", "drafts/**", "archive/2019/**"]
include = ["archive/2019/keep-this.md"]exclude and include here use the same gitignore-style syntax as .quarryignore. An
include entry re-adds a path that an exclude pattern would otherwise drop, the same way
a ! line does in a .quarryignore file.
How the two combine
When both are present, config-level rules are applied first, then any .quarryignore files
found while walking the folder. A file excluded by either mechanism is excluded; there is no
way for a .quarryignore file to override a config-level exclude, only to add more excludes
of its own or negate its own.
Checking what will be excluded
Before running a full index, preview which files a rule set would drop:
quarry index ~/notes --dry-runwould index: 1,204 files
would exclude: 318 files (see --list-excluded)Add --list-excluded to print every excluded path, useful for confirming a broad pattern
like drafts/** is not catching more than intended.
Rules for code folders
For a folder that is also a git repository, a common pattern is to reuse the existing
.gitignore conventions by copying the relevant lines into .quarryignore, since Quarry
does not read .gitignore itself. This keeps the two files independent: something you want
git to ignore is not automatically something you want left out of search, and vice versa. A
node_modules/ directory is a good candidate for both. A secrets.env file you keep out of
git for a different reason might still be worth indexing locally, since Quarry’s index never
leaves your machine.
Shared rule files
Team plans can share a .quarryignore-style rule set across every machine on the team,
stored centrally and applied automatically to matching folders on each member’s daemon. This
is a Team-only feature; see /pricing for how it differs from Pro. On Free and
Pro, rule files are always local to the machine they are written on.
Re-applying rules to an existing index
Adding or editing exclude rules does not retroactively remove already-indexed files. Run:
quarry reindex notesThis rebuilds the index from the source files using the current rules. See Index your first folder for what a rebuild does, and Project structure for what gets rewritten on disk.
Last updated Jul 8, 2026