fix(providers): codex failed toll call when JSON in arguments has Python regexp \{ JSON Error: Expecting ',' delimiter: line 1 column 41 (char 40)

1. it happens to all harness i can find with the /chat/completions endpoint
2. the model is called directly without combo though codex
3. the harness only show the delimiter error and the log of requests show 200 but the tool call json is to blam. it seems that the problem only occur when toll call has JSON in arguments that has Python regexp t=re.sub(r'~?\\\\\\\\cite\\\\{[^}]*\\\\}', '', t)\\n
4. more test shows that the bug also happen to other codex models with and without subagnets. the harness enables streaming and it can not be turned off
5. downgrading to 3.8.51 or an early 3.8.52 (sha256:baf25bf6c3c629c6a9b7df26ca766165fdda883fab030cfb6d7090049a190492) makes it work again. no configuration changes required.

@diegosouzapw

Thanks, this gives us a reproducible direction: direct Codex calls through Chat Completions streaming, regex/backslash-containing tool arguments, and a working earlier image with the same configuration. We are moving this out of waiting-for-information and checking byte-for-byte reconstruction of streamed arguments. #17300 and #17308 address duplicated tool-argument fragments, but we will verify your regex case before treating either as the same bug. A 200 request log does not establish that the client's reconstructed arguments are valid JSON.

We reproduced a matching failure condition locally using your Python-regex expression in a longer tool command: Codex-shaped Responses events were translated to Chat Completions, fragmented on both argument and SSE boundaries, and reconstructed as a client would do. On release commit 1085d959, the reconstructed JSON fails when credential redaction is enabled, while the same command passes byte-for-byte without that transform.

The production changes already proposed in #17300 (1c4853d2) and #17308 (767cbacd) each fix this reproduction. Both passed the same 28 focused checks: nine new regex/quoting/newline/redaction cases plus 19 existing credential-transform tests. Short regex commands also pass on the unchanged base; in this reproduction the failure comes from duplicating a buffered argument prefix, not from Python braces needing to be rewritten.

We are linking this diagnosis to the existing PRs instead of opening another equivalent fix. Your report does not establish whether credential redaction was enabled, so this remains a conditional match until the corrected build is checked against your original request. The issue stays open pending integration and that acceptance; these local fixtures do not certify full CI or a live Codex run.

Thanks, this is very useful: streaming on, every harness, direct Codex models, and a regression window (works on 3.8.51 and an early 3.8.52 image, breaks later).

One lead worth checking. Open PR #17300 fixes #17291, where streamed tool_calls arguments are duplicated when credentialRedactionEnabled is on: the head of the arguments is emitted twice, and a client then fails to parse the JSON. A duplicated fragment inside a long, escape-heavy argument string (like your re.sub(r'...') with many backslashes) would give exactly this kind of Expecting ',' delimiter error, while the request log still shows 200. We have not confirmed that this is your case, so please check two things:

1. Is credential redaction enabled in your settings (credentialRedactionEnabled)? If so, turn it off and repeat the same prompt. If the error disappears, it is this bug, and #17300 should fix it.
2. If it is already off, send the raw streamed tool call from the failing request (the log entry or a capture of the SSE chunks, with keys removed). Then we can see where the JSON breaks.

Either way we are tracking this as a bug now, so we are removing the needs-info label.

I turned off all the token saving features and credentialRedactionEnabled make the problem disappear but it also make the request run extremely slow.