CLI silently halts when API returns finishReason: "STOP" with empty text

[tmtd4c93aac]

What happened?

During a session, the model attempts a tool call (e.g., read_file). Upon receiving the tool output, the backend API (cloudcode-pa.googleapis.com) returns an HTTP 200 response with finishReason: "STOP" and exactly zero generated characters ("text": "").

The CLI does not handle this empty response. Because there is no text and no further tool calls, the CLI incorrectly interprets this as the model successfully concluding its task and silently returns control to the user prompt without any error, warning, or continuation.

Metadata from the logs seem to indicate no tokens were generated during this turn (promptTokenCount: 158731, totalTokenCount: 158731).

What did you expect to happen?

The CLI should detect when the model returns an empty text response with a STOP finish reason. It should, ideally, automatically retry the generation/prompt the model to continue or, as a fallback/second choice, display a visible warning to the user that the model abruptly stopped generating, rather than silently dropping the chain of thought.

Client information

Client Information

Run gemini to enter the interactive CLI, then run the /about command.

> /about
│ About Gemini CLI                                                                                                     │
│                                                                                                                      │
│ CLI Version                              0.49.0                                                                      │
│ Git Commit                               5d402f89f                                                                   │
│ Model                                    Auto                                                                        │
│ Sandbox                                  no sandbox                                                                  │
│ OS                                       linux                                                                       │
│ Auth Method                              Signed in with Google (<email>)                          │
│ Tier                                     Gemini Code Assist Standard                                                 │
│ GCP Project                              tm-gcp-emea-ai-platform                                                     │
│ IDE Client                               IDE          

Login information

Google Account (OAuth Personal)

Anything else we need to know?

This appears to be the same behavior documented in issue #10425, which was automatically closed as stale despite ongoing user reports. Note that this is distinct but related to issue #13592, which also involves silent halting in the CLI, but is triggered by finishReason: "MAX_TOKENS" token exhaustion mid-generation.

Failed Turned Request/Response

Below are the decoded request and response payloads, along with backend trace metrics associated with the failed turn, extracted from the CLI developer logs:

Decoded API Request Payload

{
  "model": "gemini-3-flash",
  "sent_turns": [
    {
      "role": "model",
      "parts": [
        {
          "text": "**Update on Progress:**\nI am going to update `REDACTED_FILE_NAME` to replace the unrecognized `start_col` and `end_col` query keys with `start_character` and `end_character`. Before applying this edit, I will read the relevant section of the file to ensure the patch is precise and correct."
        },
        {
          "thoughtSignature": "AY89a1+hxhftj7wmp/8CbcLwpPRj3ykJZm0SQBhPYHt5CJll0w7LGfcMwtcF6dkry7GYI251nWG5px2TIkwJN7GqnmUxbtDSEDRMWvn0g9WK6S0vF7zocQ0tx0bbWDXH6dr6paZ8gpEeiveQSXg5UeeuKlGrryxuqrueNc0BA+12F2fal8mYfCvHh1Cw5+2/x2NzIsZ+6r27qnsDK8uHL49Jzc9QoECdurubasT+DwYYMDjMiZroTlG0Bk4KwTVq2fTGFtahaJfPnhpSF/fC8AcWJu/v1V6ILujwWLdf0PjtC41jkvKu7cDmgKqnTYuw4FaNHYdbJ7f/Qn3T38mZy3yJVW/CuM39KoonPrRT9dXipF4QJiFYuYvMP5pg7h2UQw==",
          "functionCall": {
            "name": "read_file",
            "args": {
              "file_path": "REDACTED_FILE_NAME",
              "end_line": 100,
              "start_line": 60
            },
            "id": "read_file_1783681646463_0"
          }
        }
      ]
    },
    {
      "role": "user",
      "parts": [
        {
          "functionResponse": {
            "name": "read_file",
            "response": {
              "output": "\nIMPORTANT: The file content has been truncated.\nStatus: Showing lines 60-95 of 95 total lines.\nAction: To read more of the file, you can use the 'start_line' and 'end_line' parameters in a subsequent 'read_file' call. For example, to read the next section of the file, use start_line: 96.\n\n--- FILE CONTENT (truncated) ---\n\n    if exit_code ~= 0 or target_branch == \"\" then\n      target_branch = \"origin/master\"\n      local _, master_exit = utils.capture_shell(\"git show-ref --verify refs/remotes/origin/master\")\n\n      if master_exit ~= 0 then\n        target_branch = \"origin/main\"\n      end\n    end\n\n    commitish, exit_code = utils.capture_shell(\"git merge-base HEAD \" .. target_branch)\n    if exit_code ~= 0 then\n      print(\"falling back to master...\")\n      commitish = \"master\"\n    end\n  end\n\n  local url = endpoint .. \"/-/editor?\" .. query {\n    remote_url = remote_url,\n    branch = commitish,\n    file = relative_path,\n    start_row = start_row - 1,\n    end_row = end_row - 1,\n    end_col = end_col - 1,\n    start_col = start_col - 1,\n  }\n\n  vim.fn.system(\"xdg-open '\" .. url .. \"'\")\n\n  if os.getenv(\"TMUX\") ~= nil then\n    vim.fn.system(\"echo '\" .. url .. \"' | tmux load-buffer -w -\")\n  end\nend\n\nreturn M\n"
            },
            "id": "read_file_1783681646463_0"
          }
        }
      ]
    }
  ]
}

Decoded API Response Payload

{
  "content": {
    "role": "model",
    "parts": [
      {
        "text": ""
      }
    ]
  },
  "finishReason": "STOP"
}

Backend Trace & Connection Metadata

The following unique identifiers and trace metadata were captured from the raw network exchange for backend analysis:

• HTTP Status Code: 200
• Trace ID: 39ac7e823076d8e7 (from traceId)
• Response ID: btJQav3jOJPbmLAPx9WMcA (from responseId)
• Creation Time: 2026-07-10T11:07:26.930301Z (from createTime)
• Server Duration: 2111 ms (with HTTP header Server-Timing: gfet4t7; dur=1848)
• Client Library Versions: gl-node/24.14.0, CloudCodeVSCode/0.49.0, google-api-nodejs-client/9.11.0

[gemini-cli]

Found possible duplicate issues:

• Resolve Issue of Empty Responses From Gemini #10425

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

[gemini-cli]

Effort Analysis:
The root cause is located in packages/core/src/core/geminiChat.ts, where an InvalidStreamError is explicitly thrown when the model returns empty text with a STOP finish reason (line 1349). This error is caught in packages/core/src/core/turn.ts (line 410) and yielded as a GeminiEventType.InvalidStream event. However, packages/cli/src/ui/hooks/useGeminiStream.ts contains an incomplete implementation for this event, where ServerGeminiEventType.InvalidStream simply triggers a break with a // Will add the missing logic later comment (line 1545). Fixing this requires a cross-package refactor to implement robust UI feedback and potentially an automated retry strategy in the core generator, which involves complex React state management and asynchronous flow control, mapping directly to the effort/medium guidelines for cross-component refactors and integration issues.

[tmtd4c93aac]

I see here (#26340) that it did use to retry and that was removed on purpose.
It doesn't feel like the pros and cons were weighted correctly on that PR.
In my opinion this should be reverted or rethought, this is the number one complaint on my company's gemini slack channel. I have sometime seen it happen 5+ times in a row.