Separate fun fact: Gemini CLI blocks env vars with strings like 'AUTH' in the name. They have two separate configuration options that both let you allow specific env vars. Neither work (bad vibe coding). Tried opening an issue and a PR, and two separate vibe-coding bots picked up my issue and wrote PRs, but nobody has looked at them. Bug's still there, so can't do git code signing via ssh agent socket. Only choice is to do the less-secure, not-signed git commits.
On top of that, Gemini 3 refuses to refactor open source code, even if you fork it, if Gemini thinks your changes would violate the spirit of the intent of the original developers in a safety/security context. Even if you think you're actually making it more secure, but Gemini doesn't, it won't write your code.
Maybe it's your prompts? I've never had Gemini refuse to write any code in any context. I use it with Claude prompts, edited down, in particular to remove guardrails.
You shouldn't use Google Ai products, they are inferior. Their models are quite good. It's confusing when people use the model name when referring to a product. What's your setup?
OpenCode has a plugin that lets you add an .ignore file (though I think .agentignore would be better). The problem is that, even though the plugin makes it so the agent can't directly read the file, there's no guarantee the agent will try to be helpful and do something like "well I can't read .envrc using my read tool, so let me cat .envrc and read it that way".
This points out that agentic security flaws are worse than "systemic", they're the feature. Agents are literal backdoors.
It's so bizarre to be discussing minor security concerns of backdoors, like trying to block env vars. Of course the maintainers don't care about blocking env vars. It's security theater.
So by default you send all this to Microsoft by opening your IDE.