Allow interactive mode to stay alive even when process.stdin.isTTY is false

[Thumbby]

What would you like to be added?

I would like gemini-cli to provide a new CLI option that allows the CLI to remain active and continue listening to stdin even when stdin.isTTY is false.
Currently, the CLI immediately exits if it detects that stdin is not a TTY (for example, when launched by another program, a script, or a background service). This makes it hard to run the CLI in a programmatically controlled long-running session.

Why is this needed?

As a developer, integrating gemini-cli into other applications can be very useful.
However, when the CLI is launched programmatically (e.g., from Java, Node.js, or a backend service), stdin is usually not a TTY, which prevents the interactive mode from working.
Supporting interactive mode without a TTY would enable many valuable integration scenarios, including:

• server-side agents
• IDE or editor extensions
• browser-based or embedded terminals
• automated development tools and workflows

Additional context

Thanks for providing this great CLI tool! This feature would make it much easier to embed the CLI into other applications while still using the interactive experience.

[gemini-cli]

Found possible duplicate issues:

• Add IPC or REST API support for Gemini CLI #2145

If you believe this is not a duplicate, please remove the status/possible-duplicate label.

[Thumbby]

Found possible duplicate issues:

• Add IPC or REST API support for Gemini CLI #2145

If you believe this is not a duplicate, please remove the status/possible-duplicate label.

I think this is not a duplicate of the IPC/REST API request.
My proposal is only about allowing interactive mode to keep running when stdin is not a TTY, without introducing new protocols or server features.
Could you please remove the status/possible-duplicate label? It seems that I don't have the write access to this issue.

[alexaustin007]

@Thumbby @gemini-cli-robot Taking up this issue

[allenhutchison]

I'm curious why you wouldn't use the ACP mode for this? You can implement an ACP client in a pretty straightforward way. https://agentclientprotocol.com/overview/introduction

[Thumbby]

I'm curious why you wouldn't use the ACP mode for this? You can implement an ACP client in a pretty straightforward way. https://agentclientprotocol.com/overview/introduction

Thanks for the suggestion.
From what I understand, ACP is a standardized protocol for communication between an editor/client and an AI coding agent — it assumes the user primarily interacts through an editor/IDE and enables the editor to talk to an agent via JSON-RPC.
In my case, I’m building a standalone executable that invokes a remote CLI context outside of an editor, so using ACP may not fit that workflow as naturally.
Still, your explanation clarifies why ACP is the recommended approach for this project — appreciate the context :)