It's nice that they mention node-pty that does most of the heavy lifting for the terminal/pseudo-tty that powers this (VSCode's terminal emulator is powered by the same library).
It looks like they've added a layer on top of node-pty to allow serializing/streaming of the contents to the terminal within the mini-terminal viewports they're allocating for the terminal rendering. I wonder if they're releasing that portion as open source?
I think that this feature might have taken Gemini CLI from just Temu Claude Code with higher usage limits, to actually competitive as a tool. It'll be interesting to see how well this actually works in practice.
To be clear, the LLM is only aware of the final state of the ptty when the command exits, right? It's not a TUI computer-use model at this point from what I can tell.
Popping into nvim to check on something really quick seems immediately useful. I think I'll still want a dedicated tab or different terminal app to have my longer lived editor open but this might be nice for validating output with test runners or checking on a database entry in psql or something.
I've had to convince it to do things it should just be able to do but thinks it can't for some reason. Like reading from a file outside of the project directory- it can do it fine, but refuses to unless you convince it that no it actually can.
Also has inserted "\n" instead of newlines on a number of occasions.
I'd argue these behaviors are much more important than being able to use interactive commands.
Well, those are problems with the underlying Gemini models. It's not like the team responsible for CLI could have trained a better model instead of making this feature.
Gemini 3.0 is likely to be released soon, and likely they would improve agentic coding experience.
GPT-5 insisted on using bash commands to edit a file, despite the dedicated tool for doing this. Problem was that the bash tool it used wrapped at 80 chars, splitting some strings between lines, which then broke the code at a syntax level. It was never able to recover, I was not impressed with GPT-5
As someone who has been experimenting with AI ‑powered command‑line helpers, I think adding interactive commands to the Gemini CLI is a logical step, but it won’t be useful unless the underlying model is reliable for basic tasks. Several people here noted that Gemini sometimes refuses to read files outside the project directory or mishandles newlines; those sorts of inconsistencies undermine trust.
In a world where you have 100 options, trust is of utmost importance. The CLI’s integration with node‑pty and the ability to stream pseudo‑tty output into mini‑terminal viewports is clever, and I’d love to see that layer documented or open‑sourced so other tools can build on it. I see this feature as something you’d use for short‑lived tasks like running a quick script, checking a log, or doing a one‑off database query. For longer editing sessions I’d still use a real terminal multiplexer and editor. If Google can fix the reliability issues and make the API for interactive sessions open, that would be hella good for everyone!
i’ve had little luck getting ai systems to correctly set up networking for a set of vms. they tend to go round and round with ip tables commands that don’t ultimately solve the problem. is config fundamentally harder than writing code ?
From the blog " Gemini CLI spawns a new process within a pseudo-terminal in the background, leveraging the node-pty library...So how does this virtual terminal running in the background show up on your screen? Think of it like a video stream. Our new serializer takes a snapshot of the pseudo terminal at every moment—capturing every piece of text, every color, and even the cursor's position. These snapshots are then streamed to you, allowing you to see and interact with the terminal application in real-time. It's not just a stream of text; it's a live feed."
Aside: The demo shows git commands being run in the CLI. I absolutely hate it when devs use a commit message that says "chore: my first commit from gemini cli" - I get that it's meant for the demo, but in general too, I've seen codebases that enforce these commit prefixes such as "chore", "feat", "bugfix" etc. Is there any real value to that? Besides wasting up the 50 character limit on the first line of the commit message, I don't see anything else being done including those. Also, non-imperative commit messages?! Come on, guys!
If you manage a product that releases changelogs then by tagging commits that way you can automatically group changes into headers like that when generating your changelog from your git history. It's fairly common in open source projects. If you however are working on some internal stuff at a company, and you don't generate changelogs from your commits then doing conventional commits isn't that useful.
It was very buggy for me. You kind of have to coax it into interactive use and then some of the time it got stuck pondering once I exited the app flow and returned to the Gemini CLI (not with Ctrl-F, full exit, it closes the TUI window). It's also super laggy.
To be honest, at this point having Claude Code monitor the output of a `tmux pipe-pane` is probably going to be superior.
I couldn't tell from the post how this will affect Gemini's ability to assist better as a result.
I guess for Google this will be a treasure trove of real developer interactions to train on.
I might try this once Gemini 3 comes out. Until then, if you're running tmux or zellij, this seems like a worse user experience since you're in a subwindow and have less screen real estate to work with.
> It's not just a stream of text; it's a live feed.
LLM wrote this article it seems.
For me Gemini CLI is not as good as Claude Code and sometimes writes more code than necessary and makes it hard to maintain. but hope it gets there with gemini 3.0 release. It's open source so I can imagine it getting there faster with community contributions.
I stopped reading at that point, it was a signal that I’d just be reading another several paragraphs of repetitive prose with random bolded text. It also put such strange over emphasis on an implementation detail that is pretty much irrelevant to users which made it actively distracting on top of being an obvious LLMism.
I made a mcp that would use a pty lib to allow claude to debug a TUI app I was writing with ok-ish results. ultimately I wanted to see what was happening myself so when I need interactive I just tell it to use tmux-cli to capture the neighboring pane. https://github.com/pchalasani/claude-code-tools/blob/main/do...
maybe turning that into a mcp with more guardrails and integrated guide to the agent would make it more popwerful
Trying to use Gemini CLI is one of the most frustrating experiences with any tool I've had in over two decades of working with software.
It's seemingly very hard to understand how it should be configured at all if you don't have a personal Google account. Rather than just using your credentials to login and start, you need to find some forum posts of people that have reversed engineered that you need to use a Google Cloud environment variable, even if you are operating without a "Code Assist License" on a Google Business account.
No matter what I do on my paid subscription through Google Business with a Google Cloud project provided in the environment configured, which I had to explicitly set up just to test the CLI even though I have access to the Models through my subscription and AI Studio, I always get error 429 after one to five messages. The limits that Google claim on Gemini seem to be just a fraction of what is claimed in my case, No clearly stated reason as to why, not in the cloud console and not when using the tool itself, except for the HTTP error message.
These are not big prompts or anything of that nature. It's simple things like review a readme file or double check a single file for errors. It's been like this from the very beginning.
Even now just to verify it, I havent used Gemini for over a week, I ask it to review 3 files that are in git diff, the files are between 50-100 lines long, after checking the first file it's already on 429, on a PAID subscription, and it even states "99%" context left. So my paid subscription lets me use less than 1% of the context window and I get locked out for a unknown amount of time.
Contrasting this to both Codex and Claue Code, where you just log in and go, it's really a night and day difference. The user experience of the paid version of Gemini CLI is just utterly terrible.
<rant> How many people are running LLMs CLIs instead of using their APIs? It seems so obnoxious to me that using a CLI command is cheaper than using their APIs, hence forcing them to build these kind of work arounds.
Maybe I'm not getting it right, but it seems there are two competing paradigms which certainly with llms coding for llms, who cares. </rant>
Building an interactive shell inside their CLI seems like a very odd technical solution. I can’t think of any use case where the same context gathering couldn’t be gleaned by examining the file/system state after the session ended, but maybe I’m missing something.
On the other hand, now that I’ve read this, I can see how having some hooks between the code agent CLIs and ghostty/etc could be extremely powerful.
I have used Claude Code heavily, and I've been forced to use Gemini CLI heavily (for a particular client project).
Of all my issues with Gemini CLI (and there are many), this addresses none of them. This is a fascinating product management prioritization decision. It makes me wonder if the people who build Gemini CLI actually use Gemini CLI for real work. Because I would think that if they did, they would surely have prioritized other things.
My personal biggest issue with Gemini CLI, which is a deal breaker if I have a say in the tooling I'm using, is that if you hit a per-minute rate limit (meaning it will be resolved in a few seconds) your session is forcefully and permanently switched over to using Flash and there is nothing you can do other than manually quit and restart to get back to using Pro 2.5. The status footer line will even continue to lie to you about what model you are using. I would genuinely like to understand the use cases for which this is desirable behavior. But even IF those use cases do exist, what is the harm or difficulty in giving an option to override this behavior? These models are not interchangeable. GitHub issues have been opened for months, some even with PRs attached, with no action from Google.
For comparison, Claude Code handles this situation with a simple exponential back off until the request succeeds. That's what I want, ESPECIALLY in a CLI agent that may be running headlessly in a pipeline.
Worse is that when it hits a 429 and switches models, it will tell you that it switched models for the rest of the session and that you need to enter a new prompt — even if files remain in a partially-changed and non-compilable state. Telling it to “continue” got it to wrap up one sub-item but didn't finish the overall change. At this point I avoid using Gemini for any large changes because it’s likely to hit a 429 and result in such a non-compilable state.
35 comments
[ 3.1 ms ] story [ 64.5 ms ] threadIt looks like they've added a layer on top of node-pty to allow serializing/streaming of the contents to the terminal within the mini-terminal viewports they're allocating for the terminal rendering. I wonder if they're releasing that portion as open source?
I've had to convince it to do things it should just be able to do but thinks it can't for some reason. Like reading from a file outside of the project directory- it can do it fine, but refuses to unless you convince it that no it actually can.
Also has inserted "\n" instead of newlines on a number of occasions.
I'd argue these behaviors are much more important than being able to use interactive commands.
Gemini 3.0 is likely to be released soon, and likely they would improve agentic coding experience.
GPT-5 insisted on using bash commands to edit a file, despite the dedicated tool for doing this. Problem was that the bash tool it used wrapped at 80 chars, splitting some strings between lines, which then broke the code at a syntax level. It was never able to recover, I was not impressed with GPT-5
In a world where you have 100 options, trust is of utmost importance. The CLI’s integration with node‑pty and the ability to stream pseudo‑tty output into mini‑terminal viewports is clever, and I’d love to see that layer documented or open‑sourced so other tools can build on it. I see this feature as something you’d use for short‑lived tasks like running a quick script, checking a log, or doing a one‑off database query. For longer editing sessions I’d still use a real terminal multiplexer and editor. If Google can fix the reliability issues and make the API for interactive sessions open, that would be hella good for everyone!
Terminal serializer code: https://github.com/google-gemini/gemini-cli/blob/main/packag...
Uses @xterm/headless npm package.
To be honest, at this point having Claude Code monitor the output of a `tmux pipe-pane` is probably going to be superior.
I guess for Google this will be a treasure trove of real developer interactions to train on.
I might try this once Gemini 3 comes out. Until then, if you're running tmux or zellij, this seems like a worse user experience since you're in a subwindow and have less screen real estate to work with.
What the heck is going on in Google-land?
LLM wrote this article it seems.
For me Gemini CLI is not as good as Claude Code and sometimes writes more code than necessary and makes it hard to maintain. but hope it gets there with gemini 3.0 release. It's open source so I can imagine it getting there faster with community contributions.
but https://geminicli.com/docs/tools/shell/#enabling-interactive... > To enable interactive commands, you need to set the tools.shell.enableInteractiveShell setting to true.
Seems contradictory. I can't get it to work in either case .
It's seemingly very hard to understand how it should be configured at all if you don't have a personal Google account. Rather than just using your credentials to login and start, you need to find some forum posts of people that have reversed engineered that you need to use a Google Cloud environment variable, even if you are operating without a "Code Assist License" on a Google Business account.
No matter what I do on my paid subscription through Google Business with a Google Cloud project provided in the environment configured, which I had to explicitly set up just to test the CLI even though I have access to the Models through my subscription and AI Studio, I always get error 429 after one to five messages. The limits that Google claim on Gemini seem to be just a fraction of what is claimed in my case, No clearly stated reason as to why, not in the cloud console and not when using the tool itself, except for the HTTP error message.
These are not big prompts or anything of that nature. It's simple things like review a readme file or double check a single file for errors. It's been like this from the very beginning.
Even now just to verify it, I havent used Gemini for over a week, I ask it to review 3 files that are in git diff, the files are between 50-100 lines long, after checking the first file it's already on 429, on a PAID subscription, and it even states "99%" context left. So my paid subscription lets me use less than 1% of the context window and I get locked out for a unknown amount of time.
Contrasting this to both Codex and Claue Code, where you just log in and go, it's really a night and day difference. The user experience of the paid version of Gemini CLI is just utterly terrible.
Maybe I'm not getting it right, but it seems there are two competing paradigms which certainly with llms coding for llms, who cares. </rant>
On the other hand, now that I’ve read this, I can see how having some hooks between the code agent CLIs and ghostty/etc could be extremely powerful.
Of all my issues with Gemini CLI (and there are many), this addresses none of them. This is a fascinating product management prioritization decision. It makes me wonder if the people who build Gemini CLI actually use Gemini CLI for real work. Because I would think that if they did, they would surely have prioritized other things.
My personal biggest issue with Gemini CLI, which is a deal breaker if I have a say in the tooling I'm using, is that if you hit a per-minute rate limit (meaning it will be resolved in a few seconds) your session is forcefully and permanently switched over to using Flash and there is nothing you can do other than manually quit and restart to get back to using Pro 2.5. The status footer line will even continue to lie to you about what model you are using. I would genuinely like to understand the use cases for which this is desirable behavior. But even IF those use cases do exist, what is the harm or difficulty in giving an option to override this behavior? These models are not interchangeable. GitHub issues have been opened for months, some even with PRs attached, with no action from Google.
For comparison, Claude Code handles this situation with a simple exponential back off until the request succeeds. That's what I want, ESPECIALLY in a CLI agent that may be running headlessly in a pipeline.