If Gemini CLI appears to keep retrying after you press Esc, a recently reported issue may explain the behavior. In Gemini CLI issue #29716, a reporter says cancellation during a mid-stream retry does not immediately stop the retry loop. The report identifies Gemini CLI v0.63.0, but it does not establish that every installation or retry error is affected.

Status checked October 12, 2026: the issue is open, and a proposed fix in pull request #29670 is also open and has not been merged. There is therefore no confirmed released fix to recommend on the basis of these reports.

What is happening?

The issue describes a cancellation race in the retry path. According to the report, a retryable content error can enter another retry without checking whether the request’s abort signal has already fired. The backoff period also uses a plain JavaScript timer, which does not stop immediately when cancellation occurs.

As a result, a cancelled request may still emit retry events and telemetry, then make another API call before the cancellation is finally handled. The reporter says the same code path was present on the project’s main branch when the issue was filed.

This is a specific implementation report, not proof that all slow Gemini CLI responses share this cause. Network failures, quota errors, tool hangs, and other cancellation problems can look similar but require separate diagnosis.

What should you do if Esc does not stop the request?

1. Avoid repeatedly resubmitting the same prompt

Repeated attempts may trigger additional requests and consume more time or quota. Wait briefly to see whether the current operation exits. If it remains stuck, use the terminal’s normal interrupt mechanism only if you are comfortable interrupting the current command; Ctrl+C is documented as a way to cancel the current request, and can quit the CLI when the input is empty. See the official Gemini CLI keyboard shortcuts.

An interrupt is a practical recovery step, not a confirmed fix for this particular bug. If the terminal session contains unsaved work, preserve that work before restarting.

2. Record the version and the exact sequence

Before changing your setup, note:

  • The output of gemini --version, if available in your installation.
  • Whether the problem occurs during a streaming response or after a tool call.
  • The error immediately before the retry begins.
  • Whether pressing Esc produces a cancellation message, leaves the interface waiting, or is followed by another request.
  • Whether the behavior reproduces in a new session.

Do not include API keys, access tokens, or private prompt contents in public reports.

3. Check the official issue and pull request

Review issue #29716 and PR #29670 for maintainer responses, review status, and any linked release. Do not assume the fix is available just because a pull request exists.

The proposed change says it gates retry paths on the abort signal and replaces the raw timer with the project’s existing abort-aware delay helper. Its author also reports adding regression tests for a content error after cancellation and cancellation during the backoff. Those are claims in the pull request description; they are not the same as a merged, released, independently verified fix.

4. Update only through a verified release

Check the official Gemini CLI repository and its release notes for a version that explicitly includes the fix. If a relevant release becomes available, update through your usual trusted installation method and test whether cancellation stops further retries.

Until then, avoid installing an unreviewed fork or copying code into a production environment solely to work around the issue. If the bug blocks your work, report your version and reproduction steps in the upstream issue and follow the maintainers’ guidance.

How the proposed fix addresses the problem

The pull request describes two changes:

  1. Check cancellation before retrying. Both retry branches should respect the abort signal so that a cancelled request does not schedule another attempt.
  2. Make the backoff interruptible. Use the existing delay(ms, signal) helper instead of a raw setTimeout, allowing the wait to end when the signal is aborted.

The pull request author reports that the targeted test file and project preflight checks pass locally. Until maintainers merge the change and a release containing it is identified, treat this as a proposed fix rather than a generally available solution.

Bottom line: if Gemini CLI continues retrying after Esc, preserve your work, record the exact version and behavior, and check the upstream issue and pull request. As of October 12, 2026, the proposed cancellation fix is not confirmed as merged or released.