Hey everyone - we wanted to give you an early heads-up that we’re planning to deprecate .clineignore soon.

.clineignore was originally introduced to reduce context noise by controlling which files Cline automatically loads, such as dependencies, build artifacts, generated files, and other files that are unlikely to be relevant to a task.

However, it only affects files that Cline loads automatically into context. It was never intended to act as a security or access-control boundary. Models can still access project files through other methods, particularly shell commands, so .clineignore cannot reliably prevent access to specific files.

To avoid giving users a false sense of security, we’re removing it as a supported feature.

Still want context filtering? Here’s an alternative

For users who still want context filtering, we have a plugin that offers similar behavior:

https://docs.cline.bot/sdk/plugin-examples#block-ignored-file-access

You can Install it with:

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

The plugin uses a runtime beforeTool hook to block read_files, editor, and apply_patch calls when they target files ignored by your workspace’s .gitignore.

Important limitations

There are a few important limitations to be aware of. This is not a 1:1 replacement for .clineignore, and it should still be treated as best-effort context filtering rather than a security guardrail.

• It guards file reads and edits only.
• It does not filter search_files or list_files results.
• It does not guard shell commands.
• It uses .gitignore, not a separate .clineignore.
• It requires a Git repository.
• Plugins currently run on the Cline SDK, CLI, and Kanban. VS Code and JetBrains support will arrive as those extensions migrate onto the SDK.

For now, the .clineignore documentation will remain available for existing users while the feature is phased out, but we no longer recommend adopting it for new workflows.

Thanks for your understanding: we’re making this change so Cline’s file access behavior is clearer and less likely to be mistaken for a security boundary.

Hi founder of Cline here, we are gearing up to release a new rehaul of our extension agent harness and we would love help with testing it from folks that use local models via ollama or lm studio. I want to make sure we don't cause any regressions and qualitatively if performance feels better as we've put a ton of work into getting better output from smaller models!

1. Install the Cline Nightly build: https://marketplace.visualstudio.com/items?itemName=saoudrizwan.cline-nightly
2. Make sure to restart vs code and that you see 'Cline: Next' at the bottom right in your status bar.
3. Test it and tell us what issues you ran into (the original ones and any new ones, positive feedback welcome too!) via the form.

Thanks for helping! 🙏

We recently added Kimi K3 to ClinePass, and its adoption has been much faster than we expected.

Within three days of launch, Kimi K3 went from 0% to 16% of all open weight model tokens used through ClinePass, making it the #3 most used model on the platform.

DeepSeek V4 Pro and DeepSeek V4 Flash still account for the largest share of usage, but Kimi K3 is already closing in on them despite being the newest model in the lineup.

This is the fastest climb we’ve seen in open weights usage in Cline’s history.

Try Kimi K3 on ClinePass!

ClinePass is Cline's new subscription plan which provides 2-5x discounted access to open weights models like Kimi K3, GLM 5.2, Kimi K2.6, Qwen3.7-Max, DeepSeek V4 Pro and many others.

Use it on Cline CLI & extension with $1.99 special promo if sign up via: npm i -g cline

Curious to hear from people who have tried K3 in ClinePass.