.clineignore (deprecate soon)

Control which files and directories Cline can access in your project. This feature will be deprecated soon.

.clineignore will be deprecated 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.

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 .

This plugin covers only part of what .clineignore did:

• It guards file reads/edits (read_files, editor, apply_patch) — it does not filter search_files/list_files results or guard shell commands, so it is not a full context-reduction tool.
• It reads your .gitignore (not a separate .clineignore) and requires a Git repository.
• Plugins run on the Cline SDK, CLI, and Kanban. Support in the VS Code and JetBrains extensions arrives as they migrate onto the SDK.

See Plugins for installation details and scopes.

---

The rest of this page is the original .clineignore reference, retained for existing users while the feature is phased out.

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:

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

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.

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

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