It sounds like iterm-mcp isn’t a tool that would fit in your organization. I’m totally not trying to change that or sell you anything.
I’m curious what your thoughts are around Cursor, Windsurf, etc. Those are IDE’s that provide the model with limited access to the terminal. Where do you feel like those tools and their AI features - terminal access specifically, fall in an org like yours? Are they disallowed due to terminal access or are the limitations of those tools safe enough?
We have a whitelist set of allowed ai tools and models. Cursor for example would fit better but I think. It really depends on the user. Engineers without access to major production system are minor risk compared to our dev ops engineers. It’s an audience issue as well I think. But we don‘t make this distinction because that can constantly shift. An engineer today may or may not have more critical access then yesterday.
And it’s not about trust or anything. It’s also about liability. Our company is publicly traded which brings in a whole lot of fun when it comes to compliant topics. Who to blame when an ai disaster happens. Obviously its the operator who should monitor the output. Sadly too complicated.
> I just can’t imagine giving AI any rights to actually run commands without oversight
We’re 100% on the same page here. No one should ask Claude (or any model) to do something using their terminal and then just walk away. I hope that’s clear from the safety section of what I posted (and in the project README).
Claude REALLY wants to help, and it will go on a journey to the end of the earth to accomplish your task. If you delegate tasks to this tool then you’re going to have to babysit it.
I have yet to have anything catastrophic happen with pretty liberal usage of YOLO mode in Cursor with pretty weak “safe” instruction guardrails. Then again, I am working with dev credentials on non-critical projects, typically. It does seem like it’s a matter of time until I get prompt injected and divulge some secrets or an over-eager Claude `rm rf`’s /.
> Why would you favor this approach over say, a command line tool that can pipe input into and out of a configurable AI backend, fork subprocesses [...]
I think what you're describing is something that's built to perform agent based tasks. iterm-mcp isn't intended to be that. It's intended to be a bridge from something like Claude Desktop to iTerm. The REPL use case is a key thing to understand here.
What you're describing is great if you want to delegate "install python on my system" for example, but it doesn't support the REPL use case where you want to work with the REPL through something like Claude Desktop.
The other key use case iterm-mcp addresses is asking questions about what's sitting in the terminal right now. For example, you ran `brew install ffmpeg` and something didn't work: you can ask Claude using iterm-mcp.
> This tool seems like it locks you into iTerm2.
This tool is intended for use with iTerm2. It's not that it "locks you into iTerm2" - iterm-mcp is something that you would choose to use if you already use iTerm2.
You can do this without needing a terminal aware tool. There are tools, and it's easy to write one yourself, that tee buffers the output of every command you run, then pipe the last command into your AI tool. You could also easily support N command buffers.
Then you don't need to be locked into using iTerm2.
I see what you're saying. Yes, what you described sounds like a much better approach in terms of being terminal agnostic. It would be awesome to have a tool like iterm-mcp that supports any terminal, any OS, etc. iterm-mcp is limited specifically to iTerm.
Hi, thanks for your comment! I haven't explored that approach. Can you say more? Will using the approach that you suggested support interactive CLI utilities like a REPL? Those are use cases that I definitely want to support with this project.
It’s just in response to “it's not always clear when the job is done”. With shell integration installed, iTerm knows how to separate commands and responses (you can cmd-shift-arrow to move between them, select the entire response with a click, etc.) so I thought it might expose that knowledge. It does that just by putting a distinctive character sequence in the shell prompt, and you could do that directly if needed. Other REPLs have customizable prompts too.
I wonder how much of what iTerm knows about the current terminal state is exposed. I got it working "good enough for me" and moved on to other pieces of the puzzle. I'm sure what I did could be improved upon quite a bit. I bet you're right that there's additional juice to squeeze out of whatever iTerm exposes.
Hi, thanks for the comment! wcgw looks really cool - nice job with it!
> I wonder if there's really a need for separate write to terminal and read output functions? I was hoping that write command itself would execute and return the output of the command, saving back and forth latency.
I traded back and forth latency for lower token use. I didn't want to return gobs of output from `brew install ffmpeg` when the model really only needs to see the last line of output in order to know what to do next.
> The way I solved it is by setting a special PS1 prompt. So as soon as I get that prompt I know the task is done. I wonder if a similar thing can be done in your mcp?
What you suggested with changing the prompt is a good idea, but it breaks down in certain scenarios - particularly if the user is using a REPL. Part of my goal for this is to not have to modify the shell prompt or introduce visual indicators for the AI because I don't want the user to have to work around the AI. I want the AI to help as requested as if it's sitting at your keyboard. I don't want to introduce any friction or really any unwanted change to the user's workflow at all.
It's important to me that this work with REPL's and other interactive CLI utilities. If that weren't a design concern then I'd definitely explore the approach that you suggested.
I think you might mean use the tail command? See my other comments about not wanting to change the user’s workflow. I don’t want to get in between the user and their commands in any way. That’s what drove my design decisions.
Would you mind elaborating if I misunderstood what you meant?
I’m working on a tool called Together Gift It. Together Gift It makes managing group gift events like Christmas easier. I’m making it because my family was sending an insane amount of group texts during the holidays, and it was getting ridiculous. My favorite one was when someone included the gift recipient in the group text about what gift we were getting for the recipient.
Together Gift It solves the problem just the way you’d think: with AI.
Just kidding. It solves the problem by keeping everything in one place. No more group texts! You can have private or shared gift lists, and there are some AI features like gift idea collaboration and product search. But the AI stuff is still a work in progress.
I created a CLI tool called Promptr which is an open source developer tool that allows the user to modify their codebase using plain language. The tool sends the user’s query as well as the relevant source code to an LLM. The changes from the LLM are applied directly to the user’s filesystem eliminating the need for copy pasting. Promptr is implemented in Javascript, and it incorporates liquidjs templating so users can build a library of reusable prompt templates for common tasks and contexts.
I created a tool called Together Gift It because my family was sending an insane amount of gift related group texts during the holidays. My favorite one was when someone included the gift recipient in the group text about what gift we were getting for the person.
Together Gift It solves the problem the way you’d think: with AI. Just kidding. It solves the problem by keeping everything in one place. No more group texts. There are wish lists and everything you’d want around that type of thing. There is also AI.
I’m curious what your thoughts are around Cursor, Windsurf, etc. Those are IDE’s that provide the model with limited access to the terminal. Where do you feel like those tools and their AI features - terminal access specifically, fall in an org like yours? Are they disallowed due to terminal access or are the limitations of those tools safe enough?