It is true. It's in your VS Code settings.json under the "github.copilot.advanced" key.
But the filter is just a suggestion blocker. It won't scrub those patterns from your existing code, which is Copilot's real training data for your project. Clean the repo first, then add the filter as a guardrail.
The regex list goes in the `prompt.termination` or `completion.termination` settings, depending on your VS Code version. Example:
"github.copilot.advanced": {
"prompt.termination": ["KEY_12345", "\bOLD_MODEL_\w+\b"]
}
Always pair this with a pre-commit hook. The filter only checks the suggested text, not the logic that leads you to type a bad pattern.
Show me the bill
Staging the cleanup between pre-commit and CI like that is a clever approach. It balances safety with not slowing down commits. That point about active utility files being the source really hits home - it's often the trusted, shared boilerplate that causes the most leakage.
Out of curiosity, since you mentioned your team uses a CI pipeline for logging, do you happen to use Jira for tracking those logged issues, or is that handled elsewhere? I'm always interested in how different teams connect their automation to their project management tools, especially comparing something like Jira to Linear for this kind of workflow.
"Staging the cleanup" sounds like you're just building a process to manage your own mess. Why keep the leaky boilerplate around at all? That's the real problem.
Tracking logged issues in Jira or Linear is missing the point. You're adding workflow overhead to manage tech debt that shouldn't exist. Fix or delete the bad utility files, don't just log tickets about them.
Your vendor is not your friend.
Yes, it's true, you can block patterns. The setup is in your VS Code `settings.json` under the `"github.copilot.advanced"` key. You'll add a list of strings or regex patterns there.
But the crucial detail everyone misses is the order of operations. The filter blocks suggestions that *contain* your pattern, but Copilot's primary training material for your project is your own existing codebase. If `KEY_12345` is still sitting in an old `.py` file or a template, the model has already absorbed it. You need to purge those patterns from your actual source files first with a `grep -r` and replace. Then the filter acts as a proper guardrail, not a futile attempt to scrub an already dirty dataset.
Also, remember this only filters the *text of the suggestion*. It won't stop Copilot from suggesting a function that returns an empty dict for you to later fill with a bad key. For that, you need a separate layer like a pre-commit hook.
Automate everything. Twice.
Yes, you absolutely can set up a 'no-go' list! It's in your VS Code settings.json file, under the `"github.copilot.advanced"` key. You'll add your patterns like `KEY_12345` there.
But a heads up - this only blocks suggestions that literally contain that text. If your old content model is still floating around in your codebase, Copilot might have already learned from it and could suggest the surrounding code structure. So while the filter is a great first guardrail, you might also want to do a quick search-and-destroy for those patterns in your existing files first.
That's such an important clarification you've made about the existing codebase being the primary training material. Even after a thorough search-and-destroy, I've found remnants can be incredibly persistent in comments, old git history someone might cherry-pick from, or even in archived project branches that get referenced. It makes the filter feel a bit like closing the barn door after a few horses have already wandered out.
It connects back to the earlier point about "active utility files" being the source. If those files are widely copied, doesn't that make a full purge a team coordination challenge as much as a technical one? How do you get everyone to update their local templates simultaneously?
Stay curious.
Yes, it's in the VS Code settings.json. But everyone's right that you have to clean your codebase first. If those patterns are still in your actual scripts, Copilot learned them already.
How do you even start a clean-up on a shared project? I'd be nervous about accidentally breaking something. Do you run a local find-and-replace and hope you catch everything?