fix(agents): repair malformed tool-call args on Codex/Responses transports#75281
Conversation
|
Codex review: needs maintainer review before merge. Summary Reproducibility: yes. for the gate behavior: current main visibly excludes the requested Responses transport IDs, and the PR tests exercise the newly enabled Codex/Azure cases plus the preserved direct OpenAI Responses negative case. A captured malformed Azure live stream is not included. Next step before merge Security Review detailsBest possible solution: Land the narrow allowlist and regression coverage after exact-head CI finishes green, preserving generic Do we have a high-confidence way to reproduce the issue? Yes for the gate behavior: current main visibly excludes the requested Responses transport IDs, and the PR tests exercise the newly enabled Codex/Azure cases plus the preserved direct OpenAI Responses negative case. A captured malformed Azure live stream is not included. Is this the best way to solve the issue? Yes. A transport-ID allowlist matches the current SSE event boundary and avoids applying the repair to the WebSocket-capable generic OpenAI Responses path. What I checked:
Likely related people:
Remaining risk / open question:
Codex review notes: model gpt-5.5, reasoning high; reviewed against 56c4f9761c75. |
1fdd91b to
51b89e5
Compare
f891122 to
fca2b90
Compare
|
Rewrote this PR into a narrow maintainer commit on top of current What changed:
Verification:
Azure live was not run from my machine because there is no configured Azure Responses deployment/provider in the local OpenClaw config; the added unit coverage exercises the same repaired stream event path after provider transport mapping. |
fca2b90 to
f908e1d
Compare
f908e1d to
7a55a76
Compare
|
Landed via rebase onto current
Issue #75154 auto-closed on merge. Thanks @Nimraakram22! |
Summary
This PR broadens the malformed tool-call argument repair gate in shouldRepairMalformedToolCallArguments to include the openai-codex-responses and azure-openai-responses transports. It also addresses automated review feedback by ensuring code style compliance and narrowing the transport scope to HTTP/SSE-based Response APIs.
Context
GPT-5.5 (via Codex) and Azure-hosted models using the Responses API emit toolcall_delta events with the same partial-JSON shape as the openai-completions API. Previously, these were excluded from the repair gate, which could lead to tools receiving empty {} objects or fragmented JSON, triggering validation failures like "Missing required property".
Changes
Narrowed Transport Scope: Following review feedback, I have explicitly excluded the generic openai-responses transport. This is a safety measure because direct OpenAI sessions can route through WebSockets, which do not emit the toolcall_delta events this specific repair logic relies on ``.
Logic Implementation: Updated the gate in src/agents/pi-embedded-runner/run/attempt.tool-call-argument-repair.ts to return true for verified SSE Response transports.
Test Suite Alignment:
Added positive test cases for the enabled SSE/HTTP transports.
Added a negative test case to ensure openai-responses (WebSocket-capable) remains disabled.
Code Quality: Applied oxfmt to all touched files to satisfy the repository's formatting requirements.
Changelog Documentation: Added a fix entry at the bottom of the UNRELEASED > Fixed section of CHANGELOG.md with proper contributor attribution (thanks @Nimraakram22) and a reference to this PR (#75281) ``.
Testing Verification
Ran the targeted test suite: pnpm vitest src/agents/pi-embedded-runner/run/attempt.tool-call-argument-repair.test.ts.
Result: 8 tests passed.
Verified that azure-openai-responses and openai-codex-responses correctly return true, while openai-responses and unrelated transports (e.g., google-generative-ai) return false.
Issues
Closes #75154