Except that it can be. As was pointed out in the original issue to remove it, the feature is not disabled, it is unconfigured. Put anything in the box for the OpenAI key, valid or not, and the functionality to send data to OpenAI is active. Accidentally put a [space] in that box and it looks like there is nothing there, but it's doing things you didn't expect.
That was the wrong way to do it. The feature should have been disabled with an actual, clear toggle that shows that it is. This blew up in the developers face for a good reason.
You still have to take the action to enable the AI features even if you just have a " " character in that field, no? It doesn't send anything to openAI until you open the prompt for it to do so.
At the moment it appears that way, but that is still the wrong action. An unconfigured field is not a disabled function and there is no way in iTerm to disable the functionality. Also, the 'prompt to use OpenAI' is not OpenAI specific, it is a new button in a previous function that you could use in earlier versions for completely non-openai purposes. There isn't a OpenAI specific prompt area.
If you leave the field empty (open to accident) and you don't press this button in this function that you may use for other things (open to accident) it doesn't send data where you didn't expect it to. This is functionally equivalent to you can accidentally send data you didn't mean to. This is simply prevented with a real toggle to disable the function.
I don't know about you, but I have clicked on things I didn't mean to because I lost where the mouse is, or because I'm giving a window focus again, it is not an accident that doesn't happen.
You can accidentally click on this checkbox you're talking about, then accidentally click on the UI element that opens up the AI prompting mechanism, then accidentally type something in and send it as well. I don't understand this
This is what was claimed was happening. I received multiple warnings that iTerm2 was sending "all terminal interactions" to OpenAI's servers regardless of the absence of an API key. Packet captures showing "exfiltrated" data were represented as proof when those were created with an invalid API key, not a blank API key.