.clineignore (deprecate soon)

.clineignore filters what Cline loads automatically, but it is not a security or access-control boundary — ignored files can still be read via explicit @ mentions or shell commands. We're moving away from it as a supported feature. </Warning>

Restricting File Access with a Plugin

While .clineignore is being phased out, you can get a stronger, enforced restriction on file reads and edits with the Block Ignored File Access Cline plugin example. Unlike .clineignore, it uses a beforeTool runtime hook to actively block tool calls: when read_files, editor, or apply_patch targets a file ignored by your workspace's .gitignore file.

Install it into your project with:

cline plugin install https://github.com/cline/cline/blob/main/sdk/examples/plugins/gitignore-read-files-guard.ts --cwd .

See Plugins for installation details and scopes. </Note>

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:

# Dependencies
node_modules/
**/node_modules/

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

# Testing artifacts
/coverage/

# Environment variables
.env
.env.*

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

# Generated/minified code
*.min.js
*.map

Pattern Syntax

.clineignore uses the same pattern syntax as .gitignore:

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

What to Exclude

Start with these categories and adjust for your project:

Almost always exclude:

• Package manager directories (node_modules/, vendor/, .venv/)
• Build outputs (dist/, build/, .next/, out/)
• Coverage reports (coverage/)
• Lock files if large (package-lock.json, yarn.lock)

Exclude if present:

• Large data files (.csv, .xlsx, .sqlite, .parquet)
• Binary assets (images, fonts, videos)
• Generated code (API clients, protobuf outputs, minified bundles)
• Environment files with secrets (.env, .env.local)

Keep accessible:

• Source code you actively work on
• Configuration files Cline needs to understand (tsconfig.json, package.json)
• Documentation and READMEs
• Test files (Cline often needs these for context)

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

As noted above, explicit @ mentions still bypass these rules — for example, @/node_modules/some-package/index.js reads that file even though node_modules/ is ignored. Ignore rules control automatic loading, not explicit access.

Tips

• 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 or multi-root workspaces, each workspace root can have its own .clineignore. See Multi-Root Workspaces for details.

Related

• Cline Rules - Define persistent instructions for Cline
• Task Management - Understand how context windows work
• Auto-Compact - Automatic context compression during long tasks