feat: filter unsupported tools from Responses API requests#9
feat: filter unsupported tools from Responses API requests#9bob733870-cloud wants to merge 1 commit into
Conversation
When using Codex Desktop with `requires_openai_auth = true` and a third-party proxy (e.g. Copilot proxy), the client automatically includes `image_generation` in the tools array. Since the Copilot backend does not support this tool type, requests fail with "unsupported_value" errors. This adds a configurable filter in `handleResponses()` that strips unsupported tool types before forwarding upstream. Currently filters `image_generation`; additional types can be added to the `FILTERED_TOOL_TYPES` set. Co-Authored-By: Claude Opus 4 (1M context) <noreply@anthropic.com>
Jer-y
left a comment
Jer-y
left a comment
There was a problem hiding this comment.
Thanks for the PR. This needs changes before it is safe to merge.
The current implementation strips hosted Responses tools before routing, which can produce false-success responses and bypass the existing translatability guard for non-Responses backends. That is a behavior change in a high-risk area and should either remain upstream-aligned or be implemented as a narrowly scoped, tested compatibility path.
| const FILTERED_TOOL_TYPES = new Set(['image_generation']) | ||
| if (payload.tools?.length) { | ||
| const before = payload.tools.length | ||
| payload.tools = payload.tools.filter(t => !FILTERED_TOOL_TYPES.has(t.type)) |
There was a problem hiding this comment.
Silently dropping image_generation here changes the request semantics before routing. For direct Responses-backed models, a request that explicitly provided this hosted tool now succeeds without the tool instead of surfacing Copilot's unsupported result; for Anthropic-routed models this also removes a hosted tool before assertResponsesPayloadTranslatable, so a request that should be rejected as not translatable can be forwarded as tool-less. That conflicts with the proxy capability policy to keep upstream behavior as the source of truth and avoid false-success compatibility shims. Please either keep forwarding and let upstream reject, or gate a client-specific fallback with regression tests that preserve the existing hosted-tool rejection semantics.
2 participants
Summary
image_generation) from Responses API requests before forwarding upstreamunsupported_valueerrors when Codex Desktop includes tools that the Copilot backend doesn't supportProblem
When using Codex Desktop with
requires_openai_auth = trueand a Copilot proxy, the client automatically includesimage_generationin the tools array. Since the Copilot backend does not support this tool type, every request fails with:{"error":{"message":"The requested tool image_generation is not supported.","code":"unsupported_value","param":"tools","type":"invalid_request_error"}}This is a known issue (openai/codex#21952) where
[features].image_generation = falsein config.toml is ignored by Codex Desktop.Solution
Added a
FILTERED_TOOL_TYPESset inhandleResponses()that strips unsupported tools before forwarding. Currently filtersimage_generation; additional types can be added to the set as needed.Test plan
requires_openai_auth = trueimage_generationis stripped from requests🤖 Generated with Claude Code