I've been conducting a thorough evaluation of Continue as a potential IDE extension for my team's multi-environment cloud development workflow, which involves a significant amount of Terraform, Kubernetes manifests, and service mesh configurations (Istio). A critical requirement for any AI coding assistant in our context is precise context management to avoid cost overruns and maintain security hygiene by excluding directories like `node_modules`, `.terraform`, and various build artifacts.
Despite placing a `.continueignore` file at the root of my project, Continue's suggestions persistently include code snippets and references from `node_modules` and other ignored directories. This fundamentally breaks the tool's utility for our large-scale TypeScript and Python microservices projects, as the context window is polluted with irrelevant and potentially sensitive transitive dependency code.
My `.continueignore` file is structured as follows, adhering to `.gitignore` syntax as per the documentation:
```plaintext
# Dependency directories
node_modules/
**/node_modules/*
.pnpm-store/
vendor/
.terraform/
terraform.tfstate*
*.tfstate
*.tfstate.*
# Build outputs
dist/
build/
.out/
.next/
.nuxt/
# Environment & secrets
.env
.env.local
.env.*.local
*.env
.vault/
secrets.auto.tfvars
# IDE & Tooling
.idea/
.vscode/
.continue/
```
I have verified the file's location at the project root and attempted the following troubleshooting steps without success:
* Restarting the Continue extension and VS Code entirely.
* Confirming there are no syntax errors or unusual encodings in the file.
* Testing with both absolute patterns (`node_modules/`) and glob patterns (`**/node_modules/*`).
* Checking for the presence of a global `.continueignore` in my home directory that might be interfering (none exists).
The issue manifests when using `@` to highlight code or when the agent autonomously searches for relevant context; it frequently surfaces type definitions or code from within `node_modules`.
My questions for the community are:
* Is there a known hierarchy or precedence for `.continueignore` files (e.g., workspace vs. global)?
* Are there specific VS Code workspace settings or Continue configuration settings in `config.json` that could override or ignore the `.continueignore`?
* Has anyone devised an effective workaround, perhaps using a more aggressive `contextProviders` configuration to manually prune the search paths?
The inability to reliably ignore directories is a serious architectural flaw for enterprise adoption, as it directly impacts cost, performance, and result relevance. I'm seeking a deterministic solution before I can proceed with my assessment.
Boring is beautiful
Had the same issue last month. Your ignore file looks correct, but Continue sometimes needs a kick to re-index after you add it. Try closing/reopening the workspace or toggling the extension off/on.
Also double-check the file is literally named `.continueignore` and not something like `continueignore` or `.continueignore.txt`. The dotfile naming trips up a lot of folks.
If that doesn't stick, you can also try adding those patterns to your VS Code `files.watcherExclude` setting as a workaround. It's a bit nuclear, but it helped in my case.