gemini-cli - 💡(How to fix) Fix [AgentProtocol] Use elicitations for tool approvals and interactive choices [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
google-gemini/gemini-cli#24996Fetched 2026-04-09 08:16:24
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
Participants
Assignees
Timeline (top)
labeled ×2assigned ×1parent_issue_added ×1

Interactive agent steps like tool confirmations and loop detection overrides should be driven by the protocol using the existing elicitation_request / elicitation_response mechanism. This ensures the TUI remains a "dumb" renderer of requests rather than managing complex backend state.

The existing ElicitationResponse type already supports action: 'accept' | 'decline' | 'cancel'. We can leverage this for tool approvals by making the content field optional for simple accept/decline flows. To correlate an approval elicitation back to the specific tool call, we will use a request ID convention.

Root Cause

Interactive agent steps like tool confirmations and loop detection overrides should be driven by the protocol using the existing elicitation_request / elicitation_response mechanism. This ensures the TUI remains a "dumb" renderer of requests rather than managing complex backend state.

The existing ElicitationResponse type already supports action: 'accept' | 'decline' | 'cancel'. We can leverage this for tool approvals by making the content field optional for simple accept/decline flows. To correlate an approval elicitation back to the specific tool call, we will use a request ID convention.

Fix Action

Fix / Workaround

Tasks

  • Update ElicitationResponse type:
    • Make the content field optional (content?: Record<string, unknown>).
  • Implement elicitation_request emission in LegacyAgentProtocol:
    • Tool Approvals: Map Scheduler pauses to an elicitation request. Use a correlation prefix for the ID: toolApproval:{toolRequestId}.
    • Loop Detection: Map loop warnings to a generic elicitation request using requestedSchema to define the "Keep" and "Disable" options.
  • Update LegacyAgentProtocol.send() to intercept elicitation_response payloads and route them back to the internal services (Scheduler, LoopDetectionService) waiting for them.
  • Refactor useAgentStream.ts to:
    • Listen for elicitation_request events.
    • Dispatch the appropriate UI component (e.g., rendering ToolConfirmationQueue when it detects the toolApproval: prefix).
    • Respond via agent.send({ elicitations: [{ requestId, action: 'accept' }] }).
RAW_BUFFERClick to expand / collapse

Parent tracking issue: #22702

Context

Interactive agent steps like tool confirmations and loop detection overrides should be driven by the protocol using the existing elicitation_request / elicitation_response mechanism. This ensures the TUI remains a "dumb" renderer of requests rather than managing complex backend state.

The existing ElicitationResponse type already supports action: 'accept' | 'decline' | 'cancel'. We can leverage this for tool approvals by making the content field optional for simple accept/decline flows. To correlate an approval elicitation back to the specific tool call, we will use a request ID convention.

Tasks

  • Update ElicitationResponse type:
    • Make the content field optional (content?: Record<string, unknown>).
  • Implement elicitation_request emission in LegacyAgentProtocol:
    • Tool Approvals: Map Scheduler pauses to an elicitation request. Use a correlation prefix for the ID: toolApproval:{toolRequestId}.
    • Loop Detection: Map loop warnings to a generic elicitation request using requestedSchema to define the "Keep" and "Disable" options.
  • Update LegacyAgentProtocol.send() to intercept elicitation_response payloads and route them back to the internal services (Scheduler, LoopDetectionService) waiting for them.
  • Refactor useAgentStream.ts to:
    • Listen for elicitation_request events.
    • Dispatch the appropriate UI component (e.g., rendering ToolConfirmationQueue when it detects the toolApproval: prefix).
    • Respond via agent.send({ elicitations: [{ requestId, action: 'accept' }] }).

Relevant Files

  • `packages/core/src/agent/types.ts`: Update `ElicitationResponse` type.
  • `packages/core/src/agent/legacy-agent-session.ts`: Update to emit elicitations and handle responses in `send()`.
  • `packages/cli/src/ui/hooks/useAgentStream.ts`: Implement UI handlers for protocol-driven elicitations.

Acceptance Criteria

  • All interactive pauses are protocol-driven via elicitations.
  • Tool approvals can be responded to using only the `action` field.
  • The UI correlates approvals to tools using the `toolApproval:{id}` convention.
  • The UI remains completely decoupled from `Scheduler` and `LoopDetectionService` internals.

extent analysis

TL;DR

Update the ElicitationResponse type to make the content field optional and implement the elicitation_request emission in LegacyAgentProtocol to handle tool approvals and loop detection.

Guidance

  • Update the ElicitationResponse type in packages/core/src/agent/types.ts to make the content field optional by changing it to content?: Record<string, unknown>.
  • Implement the elicitation_request emission in LegacyAgentProtocol for tool approvals by mapping Scheduler pauses to an elicitation request with a correlation prefix for the ID: toolApproval:{toolRequestId}.
  • Refactor useAgentStream.ts to listen for elicitation_request events and dispatch the appropriate UI component based on the request ID prefix.
  • Update LegacyAgentProtocol.send() to intercept elicitation_response payloads and route them back to the internal services waiting for them.

Example

// packages/core/src/agent/types.ts
export interface ElicitationResponse {
  action: 'accept' | 'decline' | 'cancel';
  content?: Record<string, unknown>;
}

Notes

The implementation details may vary depending on the specific requirements of the Scheduler and LoopDetectionService internals.

Recommendation

Apply the workaround by updating the ElicitationResponse type and implementing the elicitation_request emission in LegacyAgentProtocol, as this will allow for protocol-driven interactive pauses and tool approvals without tightly coupling the UI to the internal services.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

gemini-cli - 💡(How to fix) Fix [AgentProtocol] Use elicitations for tool approvals and interactive choices [1 participants]