sanitize responses function call names - #10344
Merged
Merged
Conversation
tulsi-builder
force-pushed
the
fix/provider-safe-agent-names
branch
from
July 10, 2026 15:23
9f57190 to
69c1526
Compare
Collaborator
Author
|
🤖 Rebased this onto current |
The-Best-Codes
approved these changes
Jul 10, 2026
chadac
added a commit
to chadac/scooter
that referenced
this pull request
Jul 21, 2026
…ception) (#141) * fix(goose): patch Bedrock tool-name sanitization (resume ValidationException) Carry a downstream cargoPatches patch on goose-cli that sanitizes Bedrock tool names to [a-zA-Z0-9_-]+. The bug: goose surfaces an MCP tool's display name ("<Extension>: <Title Case>", e.g. "Scooter-env: Slack Respond") into a message's tool_call.name. On conversation RESUME, goose reloads that display-formatted name from its sessions.db and serializes it into the Bedrock converse request's toolUse.name, which Bedrock rejects: ValidationException: ... toolUse.name failed to satisfy constraint: Member must satisfy regular expression pattern: [a-zA-Z0-9_-]+ Once the invalid name enters the replayed history, every subsequent turn fails — the conversation is permanently wedged (only editing goose's sessions.db recovers it). Affects any conversation that used MCP tools AND was resumed. The agent-host never builds the Bedrock request (goose owns the provider end-to-end), so the fix is downstream in goose. The patch sanitizes at the three outbound sites that must agree (the tool definition in toolConfig + both ToolUseBlock builders) and keeps a lossless sanitized->original map so the name Bedrock echoes back is restored for MCP dispatch. toolResult pairs by tool_use_id, not name, so it's untouched. The sanitizer is idempotent, so an already-valid name (scooter-env__slack_respond) is a free identity round-trip. - pkgs/goose/bedrock-tool-name-sanitize.patch: the sanitizer + 4 call-site swaps + 2 Rust round-trip unit tests (run in-build; nixpkgs goose-cli.doCheck=true). - flake.nix: agent = pkgs.goose-cli.overrideAttrs { cargoPatches = [ ... ]; }. Verified: patch git-applies clean against nixpkgs' goose src; nix build .#agent compiles + passes the tests; goose --version still 1.28.0. Remove when an upstream- fixed goose is pinned (the OpenAI Responses side is already fixed in aaif-goose/goose#10344; the Bedrock side was missed). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(goose): agent-host must use the PATCHED goose (deduplicate the image + apply the fix) The bedrock patch alone made the agent-host image balloon ~455MB (1110 -> 1565 MiB, +41%) — and worse, the patch wasn't even taking effect at runtime. Root cause: the flake's `agent` attr got the patched goose, and the image's gooseLayer bakes THAT. But services/agent-host/default.nix independently took `goose-cli` via callPackage and wrapped it onto the agent-host's PATH — that's nixpkgs' UNPATCHED goose, a different store path. So the image closure shipped goose TWICE (~455MB duplicate), and the wrapper's PATH ran the unpatched goose, so `goose acp` never got the sanitizer. Fix: agent-host/default.nix takes `agent ? goose-cli`; the flake passes the patched `agent`, so the wrapper's PATH goose and the image's gooseLayer are the SAME derivation. Verified: the agent-host image closure references exactly ONE goose (the patched one) and is back to 1110 MiB (+0 vs main); the wrapper's PATH points at the patched goose. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
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
3 participants
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.
Category: fix
User Impact: Users can mention agents with spaces or symbols in their names without OpenAI Responses requests failing before the agent can respond.
Problem: Replayed function calls in the OpenAI Responses formatter forwarded tool names exactly as stored in conversation history. Agent- or frontend-derived names like
Crack Catchercan include spaces or@, which violates OpenAI'sinput[].namepattern and causes a 400 response.Solution: Reuse the existing OpenAI function-name sanitizer when serializing Responses API
function_callitems, matching the chat-completions formatter behavior and keeping display names unaffected.File changes
crates/goose-provider-types/src/formats/openai_responses.rs
Sanitizes replayed regular and frontend function-call names before placing them in the Responses API input array. Adds a regression test covering agent-style names with spaces and mention prefixes.
Tests:
cargo test -p goose-provider-types test_responses_request_sanitizes_replayed_function_call_namescargo fmt --check