Context

I'm running GPT-5.5 via the openai-codex provider (ChatGPT Plus OAuth, openai-codex-responses API) on 2026.4.27 and tracing what tool-call self-repair is active for that path. The current gate excludes my transport:

// src/agents/pi-embedded-runner/run/attempt.tool-call-argument-repair.ts:297-306
export function shouldRepairMalformedToolCallArguments(params: {
  provider?: string;
  modelApi?: string | null;
}): boolean {
  return (
    (normalizeProviderId(params.provider ?? "") === "kimi" &&
      params.modelApi === "anthropic-messages") ||
    params.modelApi === "openai-completions"
  );
}

#70294 broadened this from "Kimi-only on anthropic-messages" to also cover openai-completions, with the explicit scope boundary "this does not... broaden the helper to every transport". Commit 2ba43f5d27 fix(agents): keep tool-call repair scoped by transport reinforced the conservative stance.

The openai-responses exclusion is locked in by an explicit test:

// src/agents/pi-embedded-runner/run/attempt.tool-call-argument-repair.test.ts:69-85
it("does not enable the repair for unrelated non-kimi transports", () => {
  expect(
    shouldRepairMalformedToolCallArguments({
      provider: "openai-compatible",
      modelApi: "openai-responses",
    }),
  ).toBe(false);
});
it("keeps kimi providers off on non-anthropic non-openai-completions transports", () => {
  expect(
    shouldRepairMalformedToolCallArguments({
      provider: "kimi-coding",
      modelApi: "openai-responses",
    }),
  ).toBe(false);
});

openai-codex-responses is in the same place as openai-responses — both false. So a Plus-OAuth GPT-5.5 / Codex Mini setup runs without the repair wrapper.

Question

Is the codex/responses exclusion intentional, or is it just a "we did not yet have evidence for that transport" gap?

Specifically:

1. Does openai-codex-responses (and openai-responses, and azure-openai-responses) emit toolcall_delta events with the same partial-JSON shape as openai-completions? If yes, the repair wrapper would be a no-op for clean streams and a recovery for malformed ones — same as #70294's argument for openai-completions.
2. Or is there a known reason — e.g., Responses-API-side schema validation, different streaming encoding, prior regression — for keeping it off?

I have not actually observed malformed args on Codex yet, so I am not opening this as a bug. I am asking before considering a PR analogous to #70294 for the codex path.

What I would propose if the answer is "yes, broaden it"

• Add openai-codex-responses (and possibly openai-responses / azure-openai-responses) to the gate
• Update the existing "does not enable the repair for unrelated non-kimi transports" test to reflect the new policy
• Keep the conservative wording in the PR — "Codex/Responses report the same partial-JSON tool-call deltas" rather than "every transport"

Happy to put up a draft PR if that is the path forward, or to wait for guidance.

Environment

• OpenClaw: 2026.4.27 (82ca6ec)
• Node: v22.19.0
• OS: macOS 26.x (Tahoe beta)
• Provider: openai-codex (ChatGPT Plus OAuth)
• Model: openai-codex/gpt-5.5

cc @MonkeyLeeT — the recent gate scoping was your call (PR #70294, commit 2ba43f5d27); want to make sure I am reading the intent correctly before broadening it.