Robust Non-Interactive Mode

[jerop]

Overview

This is a comprehensive tracking issue for making Gemini CLI's non-interactive mode production-ready and suitable for automation, CI/CD pipelines, and programmatic integration. While Gemini CLI excels in interactive use, its non-interactive mode currently has several limitations that prevent reliable automation and integration with other tools.

Problem Statement

Non-interactive mode is essential for:

• Automations: Batch processing and scripted workflows e.g. code reviews
  • GitHub Actions: Reliable automation in google-github-actions/run-gemini-cli
• Third-party Integrations: Building tools and services on top of Gemini CLI

However, the current non-interactive mode suffers from:

• Critical Issues: Unreliable Error Handling (#6745), Tool Execution Failures (#6770), Input Processing Bugs (#8015)
• Integration Limitations: Limited Output Formats (#8022), Missing Command Support (#5435)
• Operational Pain Points: MCP Server Management (#4372), Session Continuity (#1530), File Input Limitations** (#3311)

Goals

1. Feature-Complete: Support for all relevant features available in interactive mode
2. Reliable & Predictable: Consistent behavior with proper error handling and exit codes

Impact

Completing this work will:

Immediate Benefits

• Unlock GitHub Actions Integration: Enable reliable CI/CD workflows with proper error handling
• Reduce Support Burden: Fewer automation failures and clearer debugging information
• Enable Enterprise Adoption: Production-ready automation capabilities for large organizations
• Improve Developer Experience: Consistent, predictable behavior across interactive and non-interactive modes

Strategic Benefits

• Ecosystem Growth: Enable third-party tools and integrations to build on Gemini CLI
• Foundation for SDK: Patterns and APIs developed here will inform future SDK development
• Usage: Open new use cases in automation, DevOps, and enterprise workflows

Relationship to Future SDK Plans

This work is complementary to, not competing with, planned SDK development:

Bridge Strategy

• Immediate Solution: Solves urgent automation needs while SDK is in exploration
• Foundation Building: JSON output schema and error handling patterns become SDK building blocks
• User Validation: Real-world usage informs SDK design decisions
• Migration Path: Users can gradually move from CLI-based to SDK-based solutions when ready

Different Use Cases

• CLI Non-Interactive: Shell scripting, CI/CD pipelines, GitHub Actions, command-line automation
• Future SDK: Direct programmatic integration, embedded applications, complex workflows with fine-grained control

---

Note: This tracking issue will be updated as work progresses and new requirements emerge. Progress is tracked through the linked sub-issues, with regular updates posted here.