I feel for the developers who work for free on an open source project but got a lot of criticism and hate thrown at them for introducing an optional feature. It’s not a feature I would use, but not using it was an simple as not entering an LLM API token.
He doesn't work for free - from what I can tell, iTerm2 is his full-time job.
I personally didn't like the feature, but from reading through the other criticisms, it seemed like there were some genuine reasons why people didn't want this feature. I don't think it's quite as simple as you make it out to be.
People have been lying to the teeth to justify bullying the dev, but come on. iTerm2 is free of charge libre software. It doesn't make a living.
Lies are lies. Lies about how this feature exfiltrates data without you knowing isn't genuine criticism either.
If you didn't like the feature, you could've done what the rest of us did and not use it. It's simple. We just carried on with our work just like we did before the update. Well, actually not exactly the same as before because we enjoyed the UI improvement that came with the update. We certainly didn't go out of our way to enable features that didn't personally interest us. Nor did we brigade the issue tracker to go on a bullying spree or posted lies after lies in public forums.
iTerm2 is a breath of fresh air compared to all the commercial crap prevalent in our industry nowadays. Trolls may have done immeasurable damage to the future of a valuable piece of software. Too bad they're not the type to take any responsibility for such actions.
What do you mean "It doesn't make a living."? From what I can tell, his full time job is working on iTerm2. Are you saying that's not true?
I didn't like the feature, so I switched to another terminal emulator. I'm not upset and I didn't bully the dev. I wasn't a paying customer so I don't expect anyone to listen to me. I just found another product that suits the way I work much better, so I'm happy all round.
If you're using a product that does not make API calls externally with your data previously in a corporate environment that has very strict controls, and they add a feature that is part of the base install package, even if opt-in, that allows it to do that, and they do not have something like Group Policy hooks to forcibly disable it from on high, then they will block the product globally until the functionality is more contained to something their compliance systems can prevent, be it via a group policy hook or blocking the install at all.
Companies take "we might make an external call with your data" very seriously, and regardless of how much you trust the external entity, adding that in is rightfully seen as a very serious concern in some environments.
This comment is aimed at the people who made this argument, not you specifically.
This is a completely ridiculous strawman.
If a corporation needs strict controls then they don't allow for auto-updated software without vetting. They could have asked for a policy to disable the integration but they didn't, instead those people screamed about how they were going to have to completely block iTerm which showed their incompetence. This was in beta for quite a while and none of these "serious IT people" cared so either they are asleep at the wheel (not vetting beta versions) or they allow for auto-updates to software they don't control, either way it screams incompetence to me.
Also we are talking about a terminal here, a tool that can connect wherever the developer tells it to connect to. Are you telling me these companies lock down where a developer can SSH to but are too stupid to block traffic to OpenAI? Or they don't lock down where a developer can SSH and therefore don't talk to me about "strict controls".
Make it make sense. It just doesn't. This argument never held any water for me.
Various people suggested or demanded various things for various reasons.
Some described company controls. Some described company policies without controls. Some described their own strong feelings.
Some had auto updated. Some had not. Some did not say.
Some supported their companies' policies. Some stressed the policies were out of their control. Some did not say.
Some asked how to make sure the integration was disabled. Some did ask for a setting an IT department could manage. Some demanded a plugin or separate build. Some said a plugin would work for them.
Many things don't make sense if you assume everyone you disagree with are a collective.
I didn't assume they were a collective. I read through many of the comments on the GitLab issue as they were happening and there wasn't as single valid complaint. Not one. Zero. Zilch.
It was opt in, full stop. That should have been the end of this aside from IT managers asking for a group policy or a was to disable the feature (in a nice way).
Everyone complaining could either not update or move to a different tool and ask for a refund... oh wait... that's right, this was open source software. And people wonder why no one wants to maintain open source software. Just add this whole ordeal to the ever-growing pile of reasons why it's almost not worth doing. People are so entitled. My personal favorite were the people that said "If you remove this I'll start support you monetarily", which I assume 99% of those people were lying through their teeth based on the lack of spike in new donations to his patreon [0].
You combined parts of different comments, ignored others, and claimed the combination represented all.
Some were IT managers. Some were users capable to speak for their IT managers. Some did not say. There was no reason comments should have been limited to identified IT managers.
Some asked how to make sure the feature was disabled. Some did ask for a group policy. Some asked for a plugin or separate build because a group policy would not satisfy their company's requirements. The maintainer solicited these requests even though he disagreed with the requirements.
Some blocked the update. Some rolled back. You must know unsupported software has costs.
Do people wonder why more people don't maintain open source software? Most people don't maintain open source software. They have reasons. I think they can imagine other people not maintaining open source software for the same reasons.
I maintained open source software. Attitudes like yours tired me more than the rude minority of users.
Patreon is 1 of 6 donation methods. And I don't think the people who offered to pay $50 meant monthly.
> Companies take "we might make an external call with your data" very seriously, and regardless of how much you trust the external entity, adding that in is rightfully seen as a very serious concern in some environments
Please don't take this as an attack to you, but one would think that environments where this is a very serious concern would also be environments that either buy software, or buy support contracts with open source developers, to make sure that what they install is compliant with their concerns.
A lot of times the open-source software is used "unofficially", where IT/security turns a blind eye to it as long as it doesn't openly violate policies.
And often the developer is not offering a support contract. They might even take umbrage at the idea of being bribed to make changes!
A lot of open-source software usage in the workplace is the equivalent of bringing your own tools to a worksite, or bringing your own knife set to the kitchen. I obviously can't see the project's finances, but funding for tools like iTerm 2 can be heavily dependent on individual users acting as patrons, making monthly donations purely out of gratitude for bringing them joy and/or improving their personal work productivity.
All of what you said is true, but I just want to add a note that I mentioned a support contract with open source developers, not necessarily the authors of the open source software in question.
It's like when a company buys a contract with an enterprise Linux distribution: the entity offering the contract didn't author the full stack (though I'd guess they have at least some kernel contributors on staff) but they can still support it in a way that keeps the compliance department of the buying company happy.
Also, your kitchen knife set example is very relevant because, from personal experience, I know this happens but I also know problems (including accidents) resulting from using a personal knife set aren't attributed to the manufacturer of the knives but instead are treated exactly as if they happened using ones provided by the business that owns the kitchen.
Not to mention that an IT department that is truly concerned about this risk would just block the AI APIs at the network level and be done with it. A competent IT department with the concerns that OP is expressing would know that there's no way for them to keep track of all the software that is implementing AI features and would make the very easy change that would solve all of those concerns at once, not go on a witch hunt against iTerm2.
This means that the only people that we're supposedly catering to here are incompetent IT departments, which doesn't seem worth the hassle for the maintainer or all of the other users.
Or, more likely, this hypothetical IT department that cares enough to block iTerm2 but doesn't care enough to block on the network level is a fiction invented by people who just really hate seeing AI added to everything.
Totally! People in these kinds of environments have no leg to stand on criticizing a free and open source project. If you don't like it, don't use it, but CERTAINLY do not demand of the developers that they honor your requests when you don't contribute to development.
I work in a company that uses many different products that (attempt to) make external API calls with extremely sensitive data, and none of these products are blocked from installation, because we block all their requests at the network level, instead.
Yes, the corporate management is useful, but not critical, and the lack of it absolutely didn't justify the generated outrage.
e: You changed this from "This is not true." to "This is not universal." in the time when I was writing this response, which is fine, but I wasn't claiming this is universally the case, I was claiming that in some environments, this is how the logic works. It's more or less the same outcome and rationale as when JetBrains had theirs in a "plugin" that you couldn't effectively block even if it was a noop because it required an API key.
Sure, in an environment where external access is not necessary or can be easily allowlisted, that works fine.
But on someone's interactive workstation, where they might need to access parts of the internet without getting explicit allowlisting of every web site, then it's a different set of tradeoffs, and not every company implements this the same way.
From the perspective of "some corporate environments will block your software if it doesn't have this feature", then I suppose I can understand the frustration that users felt.
I would argue that there's more nuance, but the feeling is reasonable - I would also be frustrated if a piece of software that I used and loved at work was in danger of being taken away because of the addition of a feature that I didn't want in the first place!
What do these companies do about browsers? If they can block at the network level, group policy to disable an app feature is moot.
Put another way: if corporate policy blocks this app but not access to OpenAI, they are not solving the underlying issue. If they already block OpenAI they don't need the application control.
Many things, browsers are pretty configurable via group policy. One possibility is to force browsers to go through a proxy that inspects all traffic, for example.
More likely they configure the operating system to force network traffic through a certain hole, or force users to manually connect to full tunnel VPN to access work resources.
Currently my employers inspect every network call made on my device, and while they do not block OpenAI, they do block us from running specific browsers that cannot have their built in “secure” DNS settings changed such that they won’t sidestep inspection.
I get emails if I visit the Eicar test file website.
In a sufficiently high-security environment, they just block all network access that doesn't go through the proxy. That's a fairly nuclear option, however, as it also blocks a lot of harmless traffic (Spotify, for example)
Which, incidentally, would render this feature useless and harmless.
It's just really hard to see the argument against the feature as anything other than an excuse for general anti-AI sentiments. Organizations that really care about this already have the tooling in place to stop all AI features in all products with just a few network-level rules. If they don't have that tooling, they're not taking it seriously and they're not going to start suddenly blocking iTerm2 because it added an optional AI feature.
They don't, actually. Network blocking is all fine and dandy until someone adds a secure proxy into their software. Shit like this is exactly why enterprise software implements policy controls (as iTerm has just done).
I think people expect browsers to go outside the LAN, though? I don't expect a termainal like iTerm2 to be sending out network requests other than maybe to see if there's an update. I think people in IT, especially ones where security is core, like that sort of thing. That said they could courteously request it get turned off rather than freak out over it (it is free after all), but I think people don't like surprises out of staples like a terminal.
You're missing the point though: the only real argument I've seen for this being extracted altogether is a corporate environment where the existence of this feature would be enough to get the application blocked. OP is questioning why that would be a reasonable approach for an IT apartment to take—if they already block OpenAI then the feature won't do anything even if configured. If they don't already block it, then there are almost certainly people in their company using OpenAI with the browser.
Network level blocking is easier and more effective, so why should iTerm2 have to go to contortions to remove an already opt-in feature that would be easily blocked by a network block?
> Companies take "we might make an external call with your data" very seriously
No, they want to be seen taking it seriously, so they say that they take it very seriously. But if you will actually audit their system you will find they do not in reality and it was just a negotiation tactic.
Having worked in such environments one of two things happen:
1. Developers are forced to use Windows and given very little CLI access. And they certainly wouldn’t be using iTerm since it’s macOS only.
2. Developers are given a Windows corporate device as well as a MacBook Pro. The MBP doesn’t have access to any corporate systems
3. Developers can access corporate systems on MBP via jamf or InTune. The corporate side of the business accepts the risk that developers can access external (read: non-vetted) services but the business has access to all internet traffic logs from your device (usually pushed into some kind of security package that monitors for suspicious traffic) plus the ability to remote wipe it. So there is a degree of trust given to the developers.
Those that are stuck with option 1 are usually the unhappiest and least productive. So it’s not something most businesses like to entertain unless senior management is very corporate and the business is considered high risk.
What's good for the goose is good for the gander. None of these companies so much as bat an eye when applying the most sweeping, invasive data collection against their users. They should be equally thrilled to have spyware on their LAN that may enable more relevant workplace experiences for their employees.
iTerm is a terminal program that only runs on MacOS.
Unless those very strict controls include either blocking at the network level accesses to IP addresses not on a pre-approved list or removing a large number of programs and libraries that are standard on MacOS the person using iTerm will have plenty of readily available ways to use external services with that data if they want to.
Heck, the free version of ChatGPT can tell you how to access ChatGPT with curl if you don't know how [1].
I specifically asked about curl, but it would also work if I asked it to suggest a MacOS command like tool: "On MacOS what command line tools could I use to ask ChatGPT a question? Assume I have a ChatGPT API key". It suggests curl, httpie, and wget and shows how to use all of them. I updated the link below to include that too.
Block it with the same mechanisms you use to block web browsers from accessing the same content. If you do that already, you’re got. If you don’t, apparently it’s not that much of an issue.
So, just because some corporate cannot keep up with their IT compliance team with new additions to existing tools in their stack (which is honestly a tedious job), should the OSS stop experimenting and shipping new 'optional' features? There are many developers who use iTerm2 outside of a corporate environment too. I, for one, developed clx[1], which is similar in nature to what iTerm's OpenAI integration is. I am happy to have this built right into my terminal. And the code is open source as well, allowing anyone to audit what actual external API calls are being made.
Considering the entire OS now supports deeply integrated ChatGPT, it’s abundantly clear that this was the case. I think George should revert this perversion of his product architecture security theater feature. It makes me angry that iTerm is a worse product now because of the anti-ai outrage.
If you download this plugin, instead of the feature being securely integrated into the main product binary, there’s a new binary on your system that takes arbitrary JSON and performs network requests. Yes I know curl exists, but thats the point: we don’t need another tool for this that’s way less scrutinized and now opens my system up for data exfiltration in ways that weren’t originally possible. It also suffers from the traditional IPC pitfalls present when not using secure XPC with app groups. It’s objectively worse.
Edit: I’m talking about the separate binary plugin when I call for George to revert. The secure defaults config that can be MDM managed is perfect, simple, and fit for purpose to secure iTerm as a product. Moving the network calls that talk to the configured openai-compatible api server a separate binary is a farce.
Are you talking about macOS Sequoia? There will be not "deep integration" of ChagtGPT, in fact you get prompted when system wants to "outsource" a request to ChatGPT and you can refuse it.
Did you watch the freaking keynote??!! It’s everywhere and it goes off device in more cases than just ChatGPT. An opt in human in the flow UX is exactly how iTerm worked anyway, you have to check a box and actively send context to OpenAI and it’s driven off user action not some silent BG process. And it uses your token instead Apple’s enterprise account so better privacy (not that Apple hasn’t done good privacy things).
And every single one of those features can be hard, locked-down disabled with a simple configuration profile. They can all be unequivocally disabled. iTerms preferences could also be managed this way, since it hooks into cfprefsd and I could make an MCX profile to set “OpenAIIntegrationEnabled” to FALSE for the prefs domain “com.whateverIterms.bundleIDis”. Unequivocal. It’s off.
You might say that I am not a bright man, and I might agree, but the way the AI integration presented in 3.5.0 was not unequivocal. Literally nothing said “this feature is disabled unless you put an API key in”. It assumed a knowledge and understanding of how this shit works, one that I do t have because I have no interest in slop portals in any of my applications, let alone one in my terminal. Instead of a checkbox for “Enable/Disable”, one I could have left set to disabled and gone about my day, I got an empty text box for an API key. So what, does it attempt to make a network call to Sam Altman’s slop machine every time I hit enter, only to fail without an API key? YeAh bUt Go rEaD tHe sOuRCE, sure, but I’ve been using iTerm since Tiger without a need to go read the source (nor become a terminal application developer in five minutes so I could understand it) and had other shit to do that day.
Mind you, OpenAI.com is NXDOMAINed on my DNS servers at home, so I didnt give a shit either way when I upgraded to 3.5.0.
People’s reactions and comments to the dev were wrong, cruel, and uncalled for, but that doesn’t mean the feature couldn’t have been introduced and presented in a way more sensitive to people’s concerns about AI, right or wrong, real or fake. And sure, the dev has every right to do whatever they want with their open source project. They don’t owe us any emotional intelligence or respect or anything, but they also dont have a right to expect everyone to be like, totally cool and vibin with whatever they do. That doesn’t mean “everyone will put up with whatever” (which is not the same as “everyone is entitled to the project”). If the dev removed all themes except for neon pink on neon green and forced your font to be Comic Sans, would the dev be entitled to do that? Sure! It’s not illegal and they don’t owe anyone anything. Would users be entitled to go “uhh, what the fuck?” Sure! It’s not illegal and they don’t owe anyone anything! It only gets gross when people start flinging insults.
Sorry I should have been more clear. Adding a secure default is awesome (I forgot whether it was in 3.5.0 or not, because it was committed early enough that it was part of the discussion from the outset when all the outrage blew up, and it wasn’t enough). It should have stopped there. The plugin is a stupid idea that makes the application less secure and more of a flight risk. IF iTerm is going to have AI integration, THEN it should be the most simple and secure implementation, not a less secure one because some people think separate binary is a better look. Sounds like we’re on the same page about management capabilities.
I just want to say thank you to the maintainers and developers of iTerm. It’s one of the tools I use most on my Mac, alongside Emacs, VS Code (heresy!), Obsidian, and Keyboard Maestro. So, thank you!
Apple should fund some of the most popular open source tools used on their Macs. They have the funds, its good marketing, it makes business sense. Nothing speaks against it.
They should, especially any open source tooling directed at Swift. I don't understand why they're so slow at some things. Hell, make an open source foundation, I'm sure there's loads of tax write offs, I know Apple loves to save on taxes.
They're kinda sorta starting down this path, as they announced a new GitHub org (swiftlang) this week, which will eventually be the home of Swift and all its related libraries, including the rewritten Foundation. This should allow outside contributors direct commit access much more easily, and allows the language to start moving more out of Apple's control.
I don't think they're going to let you claim a donation to an open source developer as some sort of charitable donation, which means the tax write off would be no different here from any other business expense.
Does iTerm give you anything over vanilla Terminal? To my eye there's a subtle delay, it must be in the order of 50-100ms in iTerm rendering that's not present in Terminal. Non-scientific measurement - i'm just going by perceived latency and comparing to something i know is a 50ms delay.
That's for interactive use, startup time is slower for iTerm2 but i don't care about that because i basically never quit the terminal.
In both iTerm2 (when i used it) and Terminal, i have a colourscheme enabled and a custom font - both of which i'm assuming have potential to slow things down.
Iterm2’s remote tmux integration is a killer feature for me. Gives you a native, normal “windows and tabs” kind of feel, but for a remote connection. You can also disconnect/reconnect without losing your windows and tabs.
You don’t need to know any tmux to use it either (except for how to launch the right mode, which is easy to script).
If you spend a lot of time SSHed to other computers, I would highly recommend trying it out.
>> Iterm2’s remote tmux integration is a killer feature
But then i need to give up nested tmux on remotes https://github.com/craigjperry2/dotfiles/blob/main/dotfiles/... - it's super convenient to have tmux nested remotely for organising work and locally for broadcasting or just convenient context switching. Even when i was an iTerm2 user, i felt vanilla tmux was just way more comfortable (copy paste buffer for example)
iTerm has input broadcasting built-in (Cmd-Opt-I for "on", add Shift for "off"), and don't even get me started on the copy-paste: iTerm can copy multiple lines off your left pane without adding the contents of your right pane to the buffer. You can also have your left pane at 44 font size and your right pane at 8.
You can save layouts (when I start iterm, it loads multiple windows on different monitors with split panes and tabs the way I like them).
More advanced search with regex support, more advanced paste (can do character encoding transformations, deal with special characters, etc), smarter and configurable text selection, autocomplete (mixed bag, TBH - I use zsh for that), more advanced snippets for repetitive commands, and triggers to notify you when things happen (long running commands finish, certain words pop up eg "error" or "compile done").
It has a basic integrated password manager that allows me to paste passwords I commonly use in the terminal with a keycombo.
It can more tightly integrate with the shell/program. You can select a point with the mouse in vim or the shell and the text cursor will go there, for example.
Some of these may have since poked their way into the built in terminal, but these are some of the main reasons I use iterm. If you spend a lot of time in the terminal, you can enhance your productivity.
I switched back to the build in terminal app a few years ago, because I don't feel like having my environment customized and live with the defaults for almost everything. The only thing I miss is having an easy way to switch between tabs in Terminal, you can do it cmd + <tab number>, but Terminal doesn't give you the number on each tab, so you have to count yourself if you more than four or five.
Terminal.app is definitely a little faster, but the appeal of iTerm 2 for me is better control over font, colors, and keyboard shortcuts. It also provides the ability to integrate the terminal with the shell much more deeply than Terminal.app, but I mostly don't use those features.
I switched to WezTerm awhile ago for my main terminal emulator, a decision I've been happy with. But I keep a copy of iTerm running so I can pull down the Quake terminal. Main uses are running homebrew updates, and, perhaps ironically given the topic of this thread, sgpt.
I'm pretty sure everyone (at least on M1 macs) are getting that 50-100ms delay. There's a perceptible lag vs Terminal.app - in the grand scheme of things it means nothing. But once you notice it... you can't unsee it!
I could write a 200 pages book about how you can use Keyboard Maestro to automate all kinds of tedious things on a Mac. Something that takes 2-20 steps to do: Create a macro in it, trigger it via shortcut or by name. Boom. I have hundreds of macros. From opening an app to fully automating processes that would take minutes to get done manually.
PS It can even record the keystrokes and play back.
I think it's important to recognize what actually changed here, because the headline makes it seem like a complete reversal, but it really isn't. It was always opt-in, but they made it more blockable/opt-in. The commit message is very useful here[1].
Excerpt:
> This release adds some safety valves to eliminate the risk of private information leaving the terminal via the AI endpoints. While an API key and explicit user action were always needed to use AI features, some users asked for an impenetrable firewall for safety and regulatory purposes.
> While an API key and explicit user action were always needed to use AI features, some users asked for an impenetrable firewall for safety and regulatory purposes
Yes, some users are truly experts at driving Open Source developers to the point of burnout.
I use iTerm2, in pretty sensitive environments, where 'OK, you didn't enable this feature', closely followed by 'not that we had Internet access here anyway, LOL' were (though-experimentally, as are all the 'concerns' of 'some users') eclipsed by 'hey, why is it a thing to enter sensitive data on command lines anyway -- should we not have ways to avoid that?'
Oh, sure. But for me, the lack of self-awareness in "my command line inputs include extremely sensitive identifiers all the time, and this is fine, if it weren't for your optional AI plugins" is especially grating.
So, like, if I ever happen to execute 'history' in any session of yours that I manage to get access to, I hit the jackpot?
Speaking for apps but also of OSes, all that crap (AI integration, "Abobe Cloud" integration, and so on etc) should be not just opt-in, but also invisible once switched off (as opposed to some icon or banner nagging you about it in the UI, or ocassional popups asking you if you want to "enable it").
I think this was not the case here they weren't nagging about anything. And it wasn't working unless you did set up a token.
But it is always the right move to refactor code like that into optional plugins especially for enterprise users where you want to be sure nothing could leak if a user had their personal token.
This got way more hate then it deserved. I believe the real and valid discussion was how do corporate networks treat this. The outcome here makes a lot of sense in that regard. But all the negative hype around AI was too much.
It's wildly unpopular among a different bubble of the developer community, mostly concentrated around Mastodon and the fediverse.
Edit: It's worth noting that it's one of the most vocal and well-organized communities in the tech world, very prone to outrage, seeing the world in black-and-white, mob justice and piling on whatever is currently unpopular.
So it's just axiomatic that people who disagree with you are coming from (any of) a list of fundamentally illegitimate motivations that you can think of? That makes life easier for you?
Do you have any evidence whatsoever that this AI stuff was unpopular among the wider community?
These kinds of cases where open source maintainers cave to pressure are almost never the result of consensus among all users. It's usually the result of a small number of people brigading the issue tracker until the maintainer gives up and does it to shut them up. Unfortunately the result is often against the interests of the wider community.
The only thing it made me realize is how much I am happy I don't have to listen to public outcry. The nastiness people showed was pretty disappointing.
It is weird that everyone has been bashing these features. What is all the negativity? I myself do not like pushing AI into everything but I think this is a great use case for LLMs. And it was already opt-in.
Just tried "find all pdf files larger than 10MB" and it came up with "find . -name "*.pdf" -size +10M". Maybe this was easy but I don't know all arguments of all cli commands by heart and it works beautifully.
Try it for macOS specific things and it chokes. It’ll hallucinate commands, send you shit for Linux, or give you stuff that worked 20 years ago. Find is an old, nearly universal command (good luck on any of the other GNU-utils commands that are 15 years newer than the binaries shipped in macOS).
I have not found an LLM that knows any of that.
When I need a find command, I open `man find` and read and learn.
This is an editorialized title. It was opt-in from the very beginning. Here's all the steps that was originally required:
1. Open settings, go to the General tab, click on the AI button.
2. Enter a paid API key
3. Close the settings
4. Click "Toolbelt" on the menu bar, and click on "Codecierge"
5. Click "Toolbelt" on the menu bar again, and click "Show toolbelt"
6. In the toolbelt, there's a textbox that you can type questions into. The textbox won't be shown if you didn't enter an API key. Only after submitting the question will the OpenAI integration be activated, and as I understand it, only for the current session.
The initial implementation already took many many clicks to run. I literally had to do nothing to not use the feature and not once was I reminded about the feature after I chose to ignore it.
Despite that, people were spreading rumors that entering an invalid API key would instantly cause iTerm to send all data to OpenAI. It's a straight up lie started by people who actually tested the feature and posted their findings on the GitLab thread about this feature.
It gets worse, people in the GitLab thread were calling for dogpiles and fantasizing about inflicting violence on Mastodon. Towards the sole maintainer of a popular free and open source software developed in his spare time.
I'll say the same thing I said [0] on yesterday's thread [1] about this:
I didn't care for the feature (I have no issues with AI/LLMs but it just wasn't useful IMHO) but the backlash was ridiculous and embarrassing for everyone complaining about an opt-in feature. The comments on the GitLab ticket and here on HN were examples of some of the worst people (or people at their worst) in our industry.
The grandstanding definitely got in the way of otherwise legitimate feedback/concerns about the feature, as sadly tends to be the case in open source software when the mob descends.
Reacting to the AI kerfuffle is all in a day's work for Mr. Nachman. He also fixed an unrelated bug I reported by the time I got up the next day. What a beast!
I actually am a large supporter of AI enhanced development workflows and I hated this feature.
I use macos SOLELY for iterm2 because of tmux integration. I was very excited for this feature.
You have to literally click the button. It's a command Y to bring up the modal, you start typing, then you have to remove hands from keyboard and mouse to the confirm button.
What the hell? No command enter, no command shift enter, maybe I missed it or did it wrong but it is literally faster to type pipx run llm prompt than control y my command mouse and click.
Just fix that one part and I would have been in heaven, also the pop up modal seems like a bad choice when it could have been directly integrated into the shell with the new overlay they introduced alongside the feature.
Bad implementation, and PLEASE if anyone knows any foss alternative to iterm2 with tmux integration please dress me down on the fool i have been and steer me towards the path of the light again.
The headline implies that "requires opt-in" is new to 3.5.1. that's not the case. The OpenAI integration always required opt in and an API token to function.
No, there's a configurable system prompt which is:
Return commands suitable for copy/pasting into \(shell) on \(uname). Do NOT include commentary NOR Markdown triple-backtick code blocks as your whole response will be copied into my terminal automatically.
The script should do this: \(ai.prompt)
And then you type your prompt in, and it returns the answer. And then you can choose to edit the command that gets returned or execute it directly.
So essentially what you'd do if you were using the API directly, just more convenient.
Hello! I really appreciate the sentiment you shared and just wanted to let you know that "grate" should be "great" in this context. I am assuming you didn't notice while using a speech to text tool or you are not a native english speaker. No hate, love to have you here, not trying to be the spelling police but your sentiment is very kind and appreciated so i thought i would let you know that a grate is a type of metal grill used mostly in filtering large masses from liquids, such as a drainage grate for flood waters.
Enjoy your day and please keep sharing your positive outlook!
You're wildly mistaken about what's going on - the feature was already opt-in. The feature literally didn't work unless you went into settings and manually entered an OpenAI key. That is literally the definition of "opt-in".
The linked release notes appear to be appropriate tweaks; a blockable plugin and needing admin rights to enable are important adjustments for corporate environments.
Just because I opt-in doesn't mean my company wants me to opt-in on their behalf.
No one stops me from opening chatgpt.com in the browser and pasting corporate stuff there. Could'nt admins just ban all access to chatgpt.com and openai.com when accessed from the corporate network? That would be a solution for all software, not just iTerm.
A few off the top of my head: iTerm starts sending the calls through a proxy for billing/analytics; iTerm adds a model selector that hits other APIs in an update.
Yes, these are useful improvements for corporate management of software - but that's not what most of the outage was about.
Also, if there wasn't a firewall that would have blocked iTerm from hitting the OpenAI APIs, then there wouldn't have been anything preventing users from just directly accessing it.
Enabling the feature was opt-in, yes, installing the feature was not (and has been made opt-in with this new update).
Apparently a lot of folks don't regard this as an critical distinction, but as someone working in a regulated industry, there is a distinction here that is worth understanding.
I was the CISO at a HIPAA-covered healthtech company and the opt-in feature as it was wouldn’t have bothered me at all. It adds nothing to the threat model that you don’t already have with curl.
Blocking at the network level is of course necessary, but it's hardly sufficient. If tomorrow your app starts directing traffic through a secure proxy, we'd have no reliable way to detect that - this is why software designed to operate in high-security environments needs built-in policy controls.
A bunch of us didn't install the update that included GPT integration. From the release notes, it appears that it was enough of a dip in updates to prompt corrective actions from the developers
Is that communication and feedback, or a boycott? For a boycott to be effective, you have to be taking something away from someone. In the case of free software, the work has already been done, for free.
They work on people without the resources to sustain operations without income. Sadly, the people that most need boycotting have effectively unlimited resources.
In the face of the Apple Intelligence macOS Sequoia announcement yesterday, anybody who is still trying to argue that moving the web request to a separate binary makes the product more secure or compliant is absolutely disingenuous and frankly malicious.
Got rid of it, switched to Kitty. I will miss the password manager from iTerm but that's ok - I can chill knowing AI won't upload my passwords someplace.
> While an API key and explicit user action were always needed to use AI features, some users asked for an impenetrable firewall for safety and regulatory purposes.
So you are saying I can rely on API key being always required by AI overlords and there would be no point in the future where somehow things leak out without needing the key?
You see if you don't meddle with my terminal data in the first place I would feel much better that I am in control of my data, and not reliant on. 3rd parties to accidentally drop guard and leak my data out.
Now you ignored everything past the first four words of what I quoted.
It doesn't "meddle or leak" your terminal data. OpenAI integration only kicks in after explicit user action. Looking at the screenshots, it appears to only become active for the current terminal pane.
Also, iTerm is developed by an actual respect-worthy person who actually cares about this kind of stuff, not by an "AI overlord." It's unfortunate that you instantly chose to make baseless spyware accusations in public forums instead of supporting him for creating the software that you've relied on.
