> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/cline/cline/llms.txt
> Use this file to discover all available pages before exploring further.

# .clineignore

> Control which files and directories Cline can access to reduce token usage and keep context focused.

The `.clineignore` file tells Cline which files and directories to skip when analyzing your codebase. It works like `.gitignore`: create a file named `.clineignore` in your project root, add patterns for files you want excluded, and Cline will ignore them.

## Why it matters

Without a `.clineignore`, Cline may load your entire project into context — including dependencies, build artifacts, and generated files. This wastes tokens, increases costs, and can push useful context out of the window.

Adding a `.clineignore` can cut your starting context from 200k+ tokens to under 50k. That means faster responses, lower costs, and the ability to use smaller, cheaper models effectively.

## Creating a .clineignore

Create a file named `.clineignore` in your project root and add patterns for files to exclude:

```text theme={null}
# Dependencies
node_modules/
**/node_modules/

# Build outputs
/build/
/dist/
/.next/
/out/

# Testing artifacts
/coverage/

# Environment variables
.env
.env.*

# Large data files
*.csv
*.xlsx
*.sqlite
*.parquet

# Generated or minified code
*.min.js
*.map
src/generated/
```

## Pattern syntax

`.clineignore` uses the same pattern syntax as `.gitignore`:

| Pattern            | Matches                                        |
| ------------------ | ---------------------------------------------- |
| `node_modules/`    | The `node_modules` directory                   |
| `**/node_modules/` | `node_modules` at any depth                    |
| `*.csv`            | All CSV files anywhere in the project          |
| `/build/`          | The `build` directory at the project root only |
| `.env.*`           | Files like `.env.local`, `.env.production`     |
| `!important.csv`   | Exception: do not ignore this specific file    |

Lines starting with `#` are comments. Blank lines are ignored.

## What to exclude

Start with these categories and adjust for your project:

<AccordionGroup>
  <Accordion title="Almost always exclude">
    * Package manager directories: `node_modules/`, `vendor/`, `.venv/`, `__pycache__/`
    * Build outputs: `dist/`, `build/`, `.next/`, `out/`, `target/`
    * Coverage reports: `coverage/`, `.nyc_output/`
    * Lock files if large: `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`

    ```text theme={null}
    node_modules/
    **/node_modules/
    dist/
    build/
    .next/
    coverage/
    ```
  </Accordion>

  <Accordion title="Exclude if present">
    * Large data files: `.csv`, `.xlsx`, `.sqlite`, `.parquet`, `.dump`
    * Binary assets: images, fonts, videos, compiled binaries
    * Generated code: API clients, protobuf outputs, minified bundles, migration snapshots
    * Environment files with secrets: `.env`, `.env.local`, `.env.production`

    ```text theme={null}
    # Data files
    *.csv
    *.xlsx
    *.sqlite
    *.parquet

    # Environment files
    .env
    .env.*

    # Generated code
    src/generated/
    *.min.js
    *.min.css
    ```
  </Accordion>

  <Accordion title="Keep accessible">
    Source code you actively work on, configuration files Cline needs to understand (`tsconfig.json`, `package.json`, `pyproject.toml`), documentation and READMEs, and test files (Cline often needs these for context when writing new tests).
  </Accordion>
</AccordionGroup>

## How it works

When Cline scans your project to build context, it checks each file path against your `.clineignore` patterns. Matching files are excluded from:

* The file listing Cline sees when starting a task
* Automatic context gathering during conversations
* Search results when Cline looks for relevant code

You can still reference ignored files explicitly using `@` mentions. If you type `@/node_modules/some-package/index.js`, Cline reads that specific file even though `node_modules/` is in your `.clineignore`. The ignore rules control automatic loading, not explicit access.

<Note>
  `.clineignore` is separate from `.gitignore`. Files tracked by Git but irrelevant to Cline — like large test fixtures or data files — should go in `.clineignore` even if they're not in `.gitignore`.
</Note>

## Full example

Here's a comprehensive `.clineignore` for a modern Node.js web project:

```text theme={null}
# ─── Dependencies ────────────────────────────────────────
node_modules/
**/node_modules/
.pnp
.pnp.js

# ─── Build outputs ───────────────────────────────────────
dist/
build/
out/
.next/
.nuxt/
.output/
.vercel/

# ─── Test artifacts ──────────────────────────────────────
coverage/
.nyc_output/
jest-results/
playwright-report/
test-results/

# ─── Environment and secrets ─────────────────────────────
.env
.env.*
!.env.example

# ─── Data files ──────────────────────────────────────────
*.csv
*.tsv
*.xlsx
*.xls
*.sqlite
*.sqlite3
*.db
*.parquet
*.dump

# ─── Generated code ──────────────────────────────────────
src/generated/
*.min.js
*.min.css
*.map

# ─── Package manager lock files (large) ──────────────────
package-lock.json
yarn.lock
pnpm-lock.yaml

# ─── Logs ────────────────────────────────────────────────
*.log
logs/
npm-debug.log*
```

## Tips

* **Add `.clineignore` early in your project.** It's easier to start with broad exclusions and narrow them than to debug why context is bloated later.
* **Check your token usage** in the task header after adding a `.clineignore`. The difference is often dramatic.
* **If Cline seems to be missing context** about a file, check whether it's being excluded by your ignore patterns.
* **For monorepos**, each workspace root can have its own `.clineignore`. Rules in each root apply to that root's file tree independently.