token drain loop

[arrancarcero]

What happened?

[ACTION REQUIRED] 📎 PLEASE ATTACH THE EXPORTED CHAT HISTORY JSON FILE TO THIS ISSUE IF YOU FEEL COMFORTABLE SHARING IT.

What did you expect to happen?

loop detection to stop problem and this shipped missing template.py causing errors repeatedly.

Client information

• CLI Version: 0.50.0
• Git Commit: 8d9733d
• Session ID: f17d5d2e-1e07-4f3d-a19d-a87f1adffe32
• Operating System: win32 v25.9.0
• Sandbox Environment: no sandbox
• Model Version: auto
• Auth Type: gemini-api-key
• Memory Usage: 376.0 MB
• Terminal Name: Unknown
• Terminal Background: #0c0c0c
• Kitty Keyboard Protocol: Unsupported

Login information

No response

Anything else we need to know?

No response

[arrancarcero]

PRODUCT ISSUE REPORT & TOKEN REIMBURSEMENT CLAIM

Product: Gemini CLI
Platform: Windows (win32)
Report Date: Saturday, July 11, 2026
Status: DISCOVERED, REPRODUCED, AND RESOLVED LOCALLY
Severity: High (Uncontrolled Client Resource & Token Consumption)

---

1. Executive Summary

This report documents a critical client-side behavior issue within the Gemini CLI. When an MCP (Model Context Protocol) server configuration experiences startup crashes or authentication failures, the Gemini CLI lacks a proper backoff or limit mechanism on its connection and update-check loops.

Instead of cleanly failing or notifying the user, the client enters an active, high-frequency infinite loop in the terminal/devtools console. In some environments, this triggers a cascading loop where the UI endlessly renders or automatically resubmits state prompts, resulting in substantial, unintended token consumption and high local CPU utilization.

We are requesting a service credit / token reimbursement for the quota wasted due to this automated, uncontrolled client loop.

---

2. Technical Breakdown & Mechanisms

Issue A: Infinite Update Check & Reconnect Loop (Client-Side)

• Trigger: An MCP extension or server (e.g., https://github.com/github/github-mcp-server) returning a standard error like 401 Unauthorized during startup update checks.
• Failure Mode: The client repeatedly tries to check for updates and refresh the context over and over again without pausing or yielding.
• Log Signature:

  ✖ Failed to check for updates for extension "https://github.com/github/github-mcp-server": Request failed with status code 401
  ℹ Scheduling MCP context refresh...
  ℹ Executing MCP context refresh...
  ℹ MCP context refresh already in progress, queuing trailing execution.
  ℹ MCP context refresh complete.
  ℹ Coalescing burst refresh requests (300ms delay)...
  ℹ Executing MCP context refresh...
  

• Impact: This loop continues indefinitely, consuming hundreds of console logs and triggering local UI/event rendering loops that lock up the display and can inadvertently send repeated status messages to the model.

Issue B: Missing Python SDK Module Crash (Dependency Packaging)

• Trigger: The built-in CLI companion server cli-mcp starting up using Python's mcp SDK (v1.23.3 in Miniconda).
• Failure Mode: The mcp.server.fastmcp.resources module tried to import ResourceTemplate from templates.py, but templates.py was completely missing from the packaging of v1.23.3.
• Traceback:

  File "C:\Users\Arran\AppData\Local\Programs\Miniconda3\Lib\site-packages\cli_mcp_server\__init__.py", line 3, in <module>
    from . import server
  File "C:\Users\Arran\AppData\Local\Programs\Miniconda3\Lib\site-packages\cli_mcp_server\server.py", line 8, in <module>
    import mcp.server.stdio
  ...
  File "C:\Users\Arran\AppData\Local\Programs\Miniconda3\Lib\site-packages\mcp\server\fastmcp\resources\resource_manager.py", line 11, in <module>
    from mcp.server.fastmcp.resources.templates import ResourceTemplate
  ModuleNotFoundError: No module named 'mcp.server.fastmcp.resources.templates'

• Impact: This packaging bug caused cli-mcp-server.exe to crash immediately on startup. Because of Issue A, the Gemini CLI constantly tried to rediscover/reconnect to it, outputting continuous error cycles to the console.

---

3. Financial & Token Consumption Impact

Because Gemini CLI passes the entire conversation/session history with each subsequent message, a client that is continuously looping or repeatedly outputting error traces in devtools consumes tokens exponentially.

• Context Multiplier: If the console or devtools prints duplicate/looping messages, and those messages are bundled into the session context sent on subsequent turns, the context size expands by thousands of tokens per turn.
• Unintentional Turns: Local terminal loops that cause rendering flickers or automated retries can artificially inflate active agent turns. At 1M+ token limit prices, a loop that runs several hundred times in devtools can quickly exhaust a user's API tier limit or accrue substantial billing charges.

---

4. Proof of Concept (PoC) / Reproduction Steps

To reproduce the terminal loop and uncontrolled update checks:

1. Install an extension with outdated/unauthorized credentials:

   gemini extensions install https://github.com/github/github-mcp-server

2. Start a standard Gemini CLI session without a GitHub PAT or with an expired token.
3. Observe the immediate 401 Unauthorized check warning followed by the continuous cascade of Executing MCP context refresh... logs.
4. Trigger the cli-mcp crash: Install mcp==1.23.3 in the local Python environment, attempt to launch a session, and watch the client constantly spam "Connection closed" errors without rate limits or backoff.

---

5. Local Fix / Workaround (Applied Successfully)

We have successfully resolved this issue locally by performing the following:

1. Disabled the problematic extension:

   gemini extensions disable github

2. Removed the failing MCP server block from user config:

   gemini mcp remove github -s user

3. Repaired the broken mcp SDK package by upgrading it to version 1.28.1 which properly includes templates.py:

   C:\Users\Arran\AppData\Local\Programs\Miniconda3\python.exe -m pip install --upgrade mcp

---

6. Compensation & Credit Request

We request that the Gemini CLI engineering/support team:

1. Audit the token logs for this user account on Saturday, July 11, 2026, to identify API calls triggered during active console loop cascades.
2. Issue a credit equivalent to the tokens consumed by these repeating background/automated context refreshes and console loop executions.
3. Implement a fix in Gemini CLI to throttle reconnection attempts and enforce standard exponential backoff for disconnected MCP servers and extension updates.

[wzg0911]

你的报告非常详尽，尤其是 Issue A 的 MCP 重连无限循环——这是一个经典的"静默吞噬"模式：认证失败→无限重试→UI重新渲染→token持续消耗。

这里有三层防御（从你的报告出发）：

1. 指数退避（最底层、最基础）
MCP 重连应当使用指数退避：第一次失败等 1s，第二次 2s，第三次 4s...第五次以上等 30s 并告警。当前代码"300ms delay + queue trailing execution"几乎是立即重试，在高频失败下直接变成死循环。

2. 断路器（第二层、更关键）
连续 3 次 MCP 连接失败后，自动 disable 那个 MCP server 并通知用户"MCP server X 连续 3 次认证失败，已暂停——请检查配置后手动启用"。这不仅节省 token，还能让用户立刻知道问题在哪（而不是看到 UI 卡死）。

3. Token 消耗审计（第三层、事后追溯）
每条 MCP 调用/重试都记录 token 消耗，形成一个 audit trail。当用户投诉"我莫名其妙被扣了几千 token"时，可以精确追溯到这条循环链。

我们在生产环境见过完全相同的模式——一个死循环 agent 在 6 小时内烧掉 $3.82 ，零产出。2 和 3 的组合可以在第一分钟就截停。

免费诊断工具，30 秒检测这种 token drain loop：ark-6ek.pages.dev/diagnose