Back to Signal Feed
CodeTracked since May 20, 2026

Fix ADK console tool confirmations to return actionable yes/no results

Added dedicated console-side handling for `toolconfirmation.FunctionCallName` so operator confirmation prompts now return a `{"confirmed": bool}` payload instead of the generic `{"result": <text>}` fallback that `ctx.ToolConfirmation()` could not consume.

adk launcher consoletool confirmation interrupttoolconfirmation.FunctionCallNamectx.ToolConfirmation

What Happened

  • Added dedicated console-side handling for `toolconfirmation.FunctionCallName` so operator confirmation prompts now return a `{"confirmed": bool}` payload instead of the generic `{"result": <text>}` fallback that `ctx.ToolConfirmation()` could not consume.
  • Added dedicated console-side handling for `toolconfirmation.FunctionCallName` so operator confirmation prompts now return a `{"confirmed": bool}` payload instead of the generic `{"result": <text>}` fallback that `ctx.ToolConfirmation()` could not consume.
  • 1 evidence item attached for review.

What is Different

Before

Scattered source updates, isolated context, and manual follow-up across multiple feeds.

Now

Implemented a targeted fix for tool-confirmation interactions: the console now renders a dedicated confirmation prompt for tool-call interrupts and parses user responses into a boolean `confirmed` field, enabling `ctx.ToolConfirmation()` to correctly apply operator approval or rejection.

Why Track This

Why It Matters

Operators using the ADK console can now actually confirm or reject sensitive tool actions (for example, deleting records), so approval-driven workflows resume correctly instead of appearing blocked by a confirmation response that was never usable. This matters most for teams running interactive HITL flows because it restores a reliable manual control path; continue to watch for regressions in other clients or scripts that still emit or expect the old `{"result": <text>}` response format.

Impact

Operators using the ADK console can now actually confirm or reject sensitive tool actions (for example, deleting records), so approval-driven workflows resume correctly instead of appearing blocked by a confirmation response that was never usable. This matters most for teams running interactive HITL flows because it restores a reliable manual control path; continue to watch for regressions in other clients or scripts that still emit or expect the old `{"result": <text>}` response format.

What To Watch Next

  • Watch whether adk launcher console becomes a repeated pattern.
  • Track follow-up changes around Tool Calling.
  • Compare future signals against this evidence trail.
  • Re-check risk flags: legacy_console_clients_still_sending_old_result_payload, edge_case_parsing_for_nonstandard_yes_no_inputs.
Open Topic TimelineOpen Technical EventOpen Original Sourcelegacy_console_clients_still_sending_old_result_payload / edge_case_parsing_for_nonstandard_yes_no_inputs / behavior_differences_between_launcher_and_other_interfaces

Supporting Evidence

GITHUB PULL REQUESTHigh Trust

google/adk-go PR #852: feat: add HITL console launcher support for tool confirmation prompts

The PR introduces a clear yes/no confirmation prompt path in `adk launcher console`, with tests validating 10 variants of user responses (e.g., `yes`, `y`, `no`, `blank`) to ensure proper boolean mapping.