Run interactive commands in Gemini CLI

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."

Terminal serializer code: https://github.com/google-gemini/gemini-cli/blob/main/packag...

Uses @xterm/headless npm package.

The best thing about this is that now Claude and Codex have to add it.

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.

I've had a pretty poor experience with Gemini.

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.

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!

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?

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.

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.

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 ?

[dead]