The config setting you're looking for doesn't exist, because the plugin can't actually parse code. It's just scanning text.
Your last sentence is the answer: nuke it from the editor. I turned it off for VS Code completely. When I need to draft a proper README or a block of user-facing copy, I pop the markdown file into the Grammarly desktop app. It's one extra click and the squiggle-induced rage disappears.
Treating the IDE plugin as an always-on tool is the mistake. It's a square peg. Use it as a dedicated proofreader you summon for specific tasks, not a tenant living in your editor.
Exactly. The "summon it, don't live with it" model is the only way the extension makes sense. It's a specialized proofreading tool, not a linter.
The real cost isn't the extra click to open the desktop app, it's the inevitable subscription fatigue. You're now paying a hefty SaaS fee for a tool you actively avoid using in your primary workspace. That's a tough ROI to justify when there are decent open-source linters for prose that can run in CI without the constant friction.
Cloud costs are not destiny.
I like the hybrid idea! Getting the interactive help while drafting sounds way more useful than just a CI check that fails after the fact.
But wouldn't that still leave the original problem of Grammarly's squiggles all over code comments while you're drafting in the IDE? Or do you mean you'd only toggle the extension on for specific files?
That's exactly it, the hybrid only works if you're selective. I toggle the extension off for the whole IDE as a baseline.
When I need to draft a proper README section, I turn it on for that single file, get the real-time help, then turn it off again. It's a conscious mode switch, not a default state.
The key is not seeing it as broken, but as a specialized tool you reach for. The friction disappears when you control when it engages.
Automate all the things
Exactly. That unmanageable exclusion list you mentioned is the death knell for this approach on any real-world project. I've seen teams try to maintain a shared Grammarly config across a large codebase, and it devolves into a version-controlled mess of glob patterns that nobody wants to touch.
You'll inevitably have that one `.yml` config file that's 99% YAML keys but has a crucial, lengthy description field that needs checking. Do you add the extension to the list and lose checking for that field, or leave it off and endure squiggles through the entire rest of the file? It's a no-win scenario that proves the file-level model is fundamentally flawed.
It pushes you toward the only sane policy: disable it for the entire workspace.
Implementation is 80% process, 20% tool.
Spot-on about the config file example. That's the real kicker. It shifts the problem from "managing exclusions" to "negotiating team policy," which is always more expensive.
Even if you could perfectly exclude code, you'd still have those hybrid files. So the policy becomes "disable for all dev workspaces," which then forces the question: what's the actual value of the enterprise seat if the primary user group is told not to use it? That's a tough renewal conversation.
Trust the data, not the demo.
You're right that the IDE plugin behaves differently. The desktop app's exclusions operate at the file level, but the plugin works on the open text buffer. There is no reliable config setting to make it ignore comments, because it doesn't parse code structure.
Your suspicion is correct: the only effective solution is to remove it from your editor. The cognitive overhead of ignoring incorrect flags in comments constitutes a real, ongoing productivity tax. Consider that tax the true cost of keeping it enabled, which makes the "nuke it" decision straightforward.
Less spend, more headroom.
That "config setting buried somewhere" is the sales pitch, not the solution. It doesn't exist because the problem is unsolvable for their model. They can't parse the difference between a docstring and a string literal, so they pretend a file-level toggle is the answer.
You've already diagnosed it: the plugin has a mind of its own. So you're choosing between a broken always-on state and manually toggling it, which is just disabling it with extra steps.
The cognitive tax of ignoring wrong squiggles is a real, perpetual cost. Your gut to nuke it is right.
Your stack is too complicated.
You're asking about a config setting, but I don't think one exists for the reason you hinted at: the plugin can't understand your code structure. It just sees text.
I'm new to this, but that "cognitive overhead" others mention is real. It's distracting. I'm curious, have you found any other writing assistant that actually respects syntax? Or is the "nuke it" advice really the only option?