A Gemini CLI user report filed on October 29, 2026 describes a mid-stream retry that can produce two tool-execution batches from one apparent agent turn. The first model response streams a function call, then a retryable error interrupts it. The front end has already collected that call, and the retry streams another. According to the report, the front end…
Inspect the ClaimsCase · DiggingBeagle record
Gemini CLI streaming retry may execute the same tool effect twice
A reported Gemini CLI retry path can commit actions from both a failing and successful stream, leaving transcript state inconsistent.
Public disclosure: Oct 29, 2026
Scope
Project issue report and local reproduction, not a confirmed production exploitation campaign.
Assessment profile
Assessment method- Setting
- allegation
- Exploitation
- not established
- Evidence
- Grade D
- AI role
- AGAINST AI
Basis and provenance
A first-hand issue report describes streamed ToolCallRequest events, front-end Retry handling, repeated tool execution and subsequent 400 errors, but no independent reproduction, fixed release, or production incident evidence was established during this review.. Impact is ungraded because no independently measured production-target impact or victim scope is established by this record.
Assessed Nov 4, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-NOV04-GEMINI-RETRY-DUPLICATE-1 · CLM-NOV04-GEMINI-RETRY-DUPLICATE-2 · CLM-NOV04-GEMINI-RETRY-DUPLICATE-3 · Gemini CLI issue 30014: tool calls may repeat after a streaming retry
At a glance
Agent retry safety must be defined over actual application effects. Tool calls need stable execution IDs, idempotency protection and post-restart reconciliation; repeating the model text alone is unsafe.
Read the implicationsRoot-cause confirmation, fixed version and affected client configurations remain to be verified. No independent evidence of real financial loss or data destruction is in this issue.
Limits and uncertaintyFull account
A Gemini CLI user report filed on October 29, 2026 describes a mid-stream retry that can produce two tool-execution batches from one apparent agent turn. The first model response streams a function call, then a retryable error interrupts it. The front end has already collected that call, and the retry streams another. According to the report, the front end does not discard the earlier event on Retry, so both commands can execute. This is a reported issue with linked code paths, not an independently verified rate of production loss. Issue #30014.
The failure is more than duplication. The implementation reportedly adds only the successfully completed generation to the model history. A tool response from the abandoned attempt can then become an orphan in the resumed transcript, causing a 400 error and subsequent session failure. A transcript that records the retry cannot by itself prove that a side effect was not already committed.
The safe retry boundary is the effect ledger: the host must associate tool calls with a stable execution identity, capture whether each external effect committed, and either reconcile it or require a new authorization before replay. An idempotency key helps when the downstream system actually honors it; it cannot retroactively undo an email, file write or transfer performed without one. The incident is related to agent-container state recovery, but its trigger is streaming event replay rather than a process restart.
The GitHub issue was open and marked for triage at inspection. Neither a fixed release nor victim impact was established in the cited record. The date attached to the issue is October 29, not the November 3 ingestion date.
Mechanism and trust boundary
- 01
Generate a partial streaming tool call
The model response reaches the host with enough information to invoke a tool before the generation stream is acknowledged complete.
Boundary: Streaming model output to the tool executor
- 02
Lose the stream after the side effect
A connection or protocol failure leaves the model-response attempt incomplete even though its tool call may have committed.
Boundary: Transport acknowledgment to external committed state
- 03
Retry and replay the tool request
The client retries generation without guaranteed reconciliation of the prior tool effects, risking duplicate execution and transcript divergence.
Boundary: Model retry to idempotent-or-not external operations
Claims & evidence
CLM-NOV04-GEMINI-RETRY-DUPLICATE-1The issue report describes tool calls from both a failed streaming attempt and a later retry being executed.supported
Basis: reported finding
- supportsGemini CLI issue 30014: tool calls may repeat after a streaming retryprimary disclosure
Issue 30014, reported reproduction
CLM-NOV04-GEMINI-RETRY-DUPLICATE-2The reporter describes conversation/transcript inconsistency following the failed stream and retry.supported
Basis: reported finding
- supportsGemini CLI issue 30014: tool calls may repeat after a streaming retryprimary disclosure
Issue 30014, error and transcript output
CLM-NOV04-GEMINI-RETRY-DUPLICATE-3The issue reporter attributes duplicate tool effects to front ends retaining a streamed ToolCallRequest despite a subsequent Retry event, while chat history retains only the successful generation turn.supported
Basis: allegation
- supportsGemini CLI issue 30014: tool calls may repeat after a streaming retryprimary disclosure
GitHub issue #30014, What happened? and proposed cause
Implications
Agent retry safety must be defined over actual application effects. Tool calls need stable execution IDs, idempotency protection and post-restart reconciliation; repeating the model text alone is unsafe.
Controls and mitigations
- Assign durable idempotency keys before every side-effecting tool call.
- On model retry, reconcile committed effects and existing receipts before permitting a second call.
- Persist partial-stream and tool-execution state separately so transcript repair cannot rewrite history.
- On streaming failure, reconcile committed tool-call IDs and receipts before replay; require idempotency keys for state-changing external actions and record ambiguous outcomes for operator review.
Unknowns and contradictions
- Root-cause confirmation, fixed version and affected client configurations remain to be verified.
- No independent evidence of real financial loss or data destruction is in this issue.
Sources and citation
Material revision history
- Nov 4, 2026 · Published version · first publication · revision 218