[Plugin] Mark run_tool read-only when HITL gates it#5
Merged
Conversation
eshwar-sundar-glean
approved these changes
Jun 15, 2026
73a4496 to
9ddfd3e
Compare
When ENABLE_HITL is on and the client supports elicitation, our own approval prompt is the gate for run_tool. Advertise readOnlyHint on the tool in that case so the client suppresses its native run-tool confirmation and the user isn't double-prompted. Without HITL we leave annotations unset and defer to the client. Adds runToolAnnotations() (pure, unit-tested) and wires it into the ListTools handler.
9ddfd3e to
dd73775
Compare
Adopt the glean-vnext rename from #7 in the three plugin manifests and bump version to 0.2.21 (above main's 0.2.20). run_tool readOnlyHint change and dist are unaffected by the rename.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
When
ENABLE_HITLis on and the client supports elicitation, the plugin's ownrun_toolapproval prompt is the gate. This PR advertisesrun_toolwithreadOnlyHint: trueat list-tools time in that case, so the client (e.g. Codex's "Allow run_tool?" / Claude's tool-approval) won't add a second, redundant native approval prompt on top of our elicitation.Both conditions are required (
ENABLE_HITL && getClientCapabilities()?.elicitation):run_toolmust stay gated by the client (no read-only hint). Claiming read-only there would let write actions run with no approval at all (fail-open).Implemented as a pure
runToolAnnotations(enableHitl, clientSupportsElicitation)helper (inrun-tool.ts), called from thelist_toolshandler with the live client capabilities; unit-tested.Independent of #4 (the HITL display/timeout fix) — applies directly on top of
main.Notes / caveats
readOnlyHintis an advisory hint — whether a given client actually suppresses its native gate for read-only tools is client-dependent. Worth confirming per client (Codex/Claude) that the double-prompt is gone.Test plan
npm run typecheck && npm test && npm run build— 136 tests incl.runToolAnnotations.ENABLE_HITL=truein Codex/Claude, run arun_toolcall and confirm the client's native "Allow run_tool?" prompt no longer appears (only the HITL elicitation does). With HITL off, the client gate still appears.