Skip to main content
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: 
# 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:
PatternMatches
node_modules/The node_modules directory
**/node_modules/node_modules at any depth
*.csvAll CSV files anywhere in the project
/build/The build directory at the project root only
.env.*Files like .env.local, .env.production
!important.csvException: 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:
  • 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
node_modules/
**/node_modules/
dist/
build/
.next/
coverage/
  • 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
# Data files
*.csv
*.xlsx
*.sqlite
*.parquet

# Environment files
.env
.env.*

# Generated code
src/generated/
*.min.js
*.min.css
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).

​
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.
.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.

​
Full example

Here’s a comprehensive .clineignore for a modern Node.js web project: 
# ─── 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.