You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Claude Code requests routed through an openai/* model work for text-only turns, but tool calls do not round-trip through the Messages/Responses bridge. When Codex returns a function_call, the bridge drops it and Claude Code receives an empty response with stop_reason: "end_turn".
Multi-turn tool transcripts also use invalid Responses input shapes: function_call and function_call_output are nested inside message content, and assistant text is encoded as input_text.
Steps to reproduce
Configure an OpenAI subscription account and an openai/* model.
Ask Claude Code to perform a task that requires a tool, such as reading a file.
Let the request continue into the tool-result turn.
Expected behaviour
Codex function_call output is returned to Claude Code as an Anthropic tool_use block.
The following tool_result is sent back as a top-level Responses function_call_output item using the same call_id.
Streaming and non-streaming responses preserve text/tool ordering and return stop_reason: "tool_use" when a tool is requested.
Actual behaviour
The response mapper keeps text items only, so function calls disappear. On the next turn, the request converter nests call/result items inside message content; the Codex backend rejects that shape with HTTP 400.
Environment
OS: macOS 26.5
Node.js version: v26.4.0
cc-router version: 0.6.2 (main)
Mode: standalone
Logs
No proxy error is emitted for the dropped response item. The invalid follow-up request is rejected by the Codex backend with HTTP 400 invalid_value.
Thank you for the detailed report and for following up with PR #9. We reviewed the implementation and the core fix is valuable, but found a few safety edge cases around incomplete tool calls, non-function Responses items, and refusals. We requested focused changes and negative-path tests before merging. We will keep this issue open and re-review the PR once those updates are ready. Thanks again for contributing to CC-Router.
@unohee Thank you again for the detailed report and for contributing the original fix in #9. We have now merged it together with the additional hardening identified during review: handling non-function Responses output items safely, rejecting invalid or incomplete tool calls and SSE streams, preserving refusals, and validating tool call IDs, names, and arguments.
When you have a chance, could you please test the latest main in your original Claude Code setup and confirm that the tool-call round trip works correctly for you? If anything still behaves unexpectedly, please reply here with the details and we will take another look.
Activity
VictorMinemu commentedon Aug 28, 2026
Thank you for the detailed report and for following up with PR #9. We reviewed the implementation and the core fix is valuable, but found a few safety edge cases around incomplete tool calls, non-function Responses items, and refusals. We requested focused changes and negative-path tests before merging. We will keep this issue open and re-review the PR once those updates are ready. Thanks again for contributing to CC-Router.
VictorMinemu commentedon Aug 28, 2026
@unohee Thank you again for the detailed report and for contributing the original fix in #9. We have now merged it together with the additional hardening identified during review: handling non-function Responses output items safely, rejecting invalid or incomplete tool calls and SSE streams, preserving refusals, and validating tool call IDs, names, and arguments.
When you have a chance, could you please test the latest
mainin your original Claude Code setup and confirm that the tool-call round trip works correctly for you? If anything still behaves unexpectedly, please reply here with the details and we will take another look.Thanks again for helping improve CC-Router!