Override for hardcoded "security concern" files - and automatic updates.

[Laransec]

There is nothing in documentation regarding an override for the "security concern" files specified in core/indexing/ignore.ts
I have many projects that use "config.json" for a real configuration file that the LLM needs access to.

Especially when the automatic update blows away my custom built CLI client.

Also a way to disable autoupdates on launch. I couldn't find anything on this in documentation.

I will attempt to build this in, but I'm not super familiar with node js so if there is someone that will take it on it would come out much better.

[darfaz]

I run into this too — config.json is a common filename that gets flagged by the hardcoded list in ignore.ts.

Until there's an official override setting, you can work around it by:

1. Adding a .continueignore file (if supported) or modifying the ignore list in your local installation
2. Renaming configuration files to avoid the flagged patterns (not ideal but works)

For the broader point about auto-updates blowing away customizations — this is a real pain point. A continue.config.json or similar user-level override file that survives updates would be the right fix.

That said, the security concern flagging exists for a good reason. Files like config.json often contain API keys, database credentials, or other secrets that you don't want accidentally sent to an LLM as context. In enterprise settings, accidentally including a .env or config file in the context window is a real data leakage vector.

A good middle ground would be: allow overrides, but log/warn when overridden files are included in context. That way teams can make informed decisions while still having visibility into what's being sent to the model.

[Laransec]

Is this an AI reply? Because it entirely doesn't understand the problem and provided a solution that doesn't exist.

.continueignore only set files to be ignored. It doesn't work the other way. - All the LLMs came up with this as a valid option to parse config.json. It doesn't seem to work that way.

Not being able to manage the blacklist is a horrible design decision. Renaming the file is a horrible option, because its part of a build pipeline.