What Problem This Solves

The azure-openai-responses provider creates OpenAI/AzureOpenAI SDK clients without a custom fetch option, so all SSE streaming responses are read without any byte cap. A buggy or hostile endpoint returning text/event-stream with a large or never-ending body is fully buffered into memory by the SDK's internal HTTP layer — an OOM / DoS vector.

This injects buildGuardedModelFetch as the SDK fetch option in both the OpenAI-compatible and native AzureOpenAI client constructors, using the resolved Azure base URL (from options, env, resource name, or model.baseUrl) so SSRF policy and exact-origin trust evaluate the actual request origin. The shared sanitizeOpenAISdkSseResponse caps oversized SSE buffer boundaries (64 KiB per unterminated event, from #96989) and oversized JSON bodies synthesized into SSE (16 MiB cumulative).

The non-OK body cap (4xx/5xx) is applied lazily inside the shared sanitizeOpenAISdkSseResponse guard via TransformStream. The previous per-provider eager wrapper in #97217 read the entire non-OK body before the SDK saw the response, breaking the OpenAI SDK's retry/cancel semantics for retryable 4xx/5xx. This PR uses the lazy shared-guard pattern that closed that defect.

Changes

No new abstraction — reuses the existing buildGuardedModelFetch and SSE_SANITIZE_BUFFER_MAX_BYTES from provider-transport-fetch.ts. The new capNonOkResponseBodyLazily helper is a small inline TransformStream that fires the cap on pull, not eager.

• src/llm/providers/azure-openai-responses.ts:4 — import buildGuardedModelFetch from provider-transport-fetch.js.
• src/llm/providers/azure-openai-responses.ts:202,206,217 — after resolving baseUrl via resolveAzureConfig, create buildGuardedModelFetch({ ...model, baseUrl }) with the resolved URL. Inject the result as fetch: into both SDK constructor branches (OpenAI path and AzureOpenAI path). No per-provider wrapper.
• src/agents/provider-transport-fetch.ts:99 — new capNonOkResponseBodyLazily(response, maxBytes) helper: wraps response.body in a pipeThrough(TransformStream) that caps at maxBytes and controller.terminate()s the source once the cap is reached.
• src/agents/provider-transport-fetch.ts:138 — sanitizeOpenAISdkSseResponse now applies capNonOkResponseBodyLazily when !response.ok and response.body is present, closing the shared-guard gap for all SDK providers (not just Azure).
• src/agents/provider-transport-fetch.test.ts — 2 inline tests at the buildGuardedModelFetch describe block:
  • "caps non-OK response body lazily so SDK can still cancel retryable responses" — 100 KiB 429 body → text.length ≤ 64 KiB after await response.text().
  • "preserves SDK ability to cancel retryable non-OK responses before reading body" — 80 KiB 503 body, await response.body?.cancel() does not pull the full payload from the source.

Design Rationale

Why fetch injection with resolved baseUrl? buildGuardedModelFetch uses model.baseUrl for SSRF origin trust and policy resolution. The Azure provider resolves the final base URL from a cascade (option → env → resource name → model.baseUrl). Spreading the resolved URL into the model ensures SSRF and exact-origin trust evaluate the actual request origin.

Why apply the cap in the shared guard instead of per-provider? Closes the gap for every SDK provider in one place with the same SSE_SANITIZE_BUFFER_MAX_BYTES boundary. Per-provider wrappers risk behavioral drift and complicate the fix for sibling providers (OpenAI Responses, OpenAI Completions, etc.).

Why lazy via TransformStream? The OpenAI SDK may want to cancel a retryable 4xx/5xx response and retry before reading the body. An eager wrapper that pre-reads the body in fetch would destroy that capability. A TransformStream only pulls when the consumer pulls, and controller.terminate() is the cap's stop signal — the source is never drained if the consumer cancels.

Why preserve the existing "non-OK small body for error parsing" test path? The lazy cap terminates the source only once accumulated bytes exceed the cap. A small non-OK body (e.g. 4xx JSON error) is unaffected — the consumer reads the full body via response.json() and gets the error message unchanged. The existing "preserves non-OK SSE bodies for provider HTTP error parsing" test continues to pass against the new shared-guard path.

Real behavior proof

Real local HTTP-server proof (local-only proof script, not committed — per checklist #23): a real node:http server on 127.0.0.1 streams a non-OK body through a 3-step vitest proof. The proof script runs the production buildGuardedModelFetch pipeline (with fetchWithSsrFGuard re-pointed at the real fetch() so the network roundtrip is real), and the lazy cap fires inside the production sanitizeOpenAISdkSseResponse.

=== Real local HTTP-server proof: lazy non-OK body cap ===

  PASS  1/3 server bytesSent=73728 → response.text() length=65536 ≤ 64 KiB
            100 KiB 429 body streamed over real HTTP; cap fires at 64 KiB; source not drained

  PASS  2/3 server bytesSent=16384 < 163840 (160 KiB) after cancel
            160 KiB 503 body; SDK cancels body before reading; server only sent 16 KiB (10% of full payload)

  PASS  3/3 small 400 body preserved for error parsing — message="API key expired"
            4xx JSON body of <1 KiB round-trips intact through the lazy cap wrapper

Mock-based regression coverage (committed provider-transport-fetch.test.ts): 78/78 vitest tests pass, including 2 inline tests for the new non-OK cap and SDK cancel behavior, plus the existing "preserves non-OK SSE bodies for provider HTTP error parsing" test which proves small error bodies are not affected by the cap.

Test suite totals (after this patch):

• provider-transport-fetch.test.ts: 78/78 passed

• azure-openai-responses.test.ts: 4/4 passed

• Behavior addressed: Non-OK response bodies (4xx/5xx) are now lazily capped at 64 KiB by the shared sanitizeOpenAISdkSseResponse guard, closing the unbounded response.text() OOM path while preserving the OpenAI SDK's ability to cancel and retry. All Azure Responses requests route through buildGuardedModelFetch with the resolved base URL.

• Real environment tested: Linux x86_64, Node 22, real node:http server on 127.0.0.1 streaming chunked transfer responses.

• Exact steps or command run after this patch:

  node scripts/run-vitest.mjs src/agents/provider-transport-fetch.test.ts --run
  node scripts/run-vitest.mjs src/llm/providers/azure-openai-responses.test.ts --run

• Evidence after fix: 82/82 vitest tests passed across the 2 committed test files. The real-server proof shows the cap truncating a 100 KiB body to exactly 64 KiB (73728 → 65536, byte-for-byte). The cancel test shows the server only sent 16384 bytes (10% of the 160 KiB total) when the SDK cancelled the body before reading, proving the lazy semantics.

• Observed result after fix: All Azure Responses requests now go through guarded transport (SSRF, timeout, SSE/JSON synthesis caps, plus the new 64 KiB non-OK cap). SDK can still call body.cancel() on a 429/5xx response before reading — verified by the cancel test, which confirms the source stream is not drained on cancel.

• What was not tested: Live Azure endpoint (proof exercises the same production fetch pipeline against the same attack shapes; real credentials not required). End-to-end test through the Azure SDK constructor requires a real Azure endpoint — the proof exercises the exact sanitizeOpenAISdkSseResponse codepath that buildGuardedModelFetch invokes.

Out of scope

Closes the loop on #97217 (closed as superseded by this PR — see comment thread). Companion to openai-responses (#97139) and openai-completions (#97228) guarded-fetch rollout. The non-OK body cap now lives in the shared guard rather than per-provider.

Diff stats

3 files changed, 119 insertions(+), 1 deletion(-)
  src/agents/provider-transport-fetch.ts        +31/-1   (capNonOkResponseBodyLazily helper + sanitize cap path)
  src/llm/providers/azure-openai-responses.ts  +4/-0    (buildGuardedModelFetch import + fetch injection)
  src/agents/provider-transport-fetch.test.ts  +84/-0   (2 new inline tests: cap + cancel)

Net change: +31 lines production code (the capNonOkResponseBodyLazily helper + fetch injection), +84 lines committed test code, +0 real-server proof in repo. The real local HTTP-server proof was captured locally and lives in the PR body only — not committed, per the proof-script-not-committed checklist rule (#23).

Risk checklist

• User-visible behavior change? Yes — existing Azure Responses requests now go through guarded transport (SSRF, timeout, SSE/JSON synthesis caps, plus the new 64 KiB non-OK cap). Non-OK error bodies are capped at 64 KiB.
• Config/env/migration change? No.
• Security/auth/secrets/network/tool-execution change? Yes — closes OOM/DoS vector via lazy cap on non-OK bodies. No new auth or secrets surface.
• Highest-risk area: Guarded fetch may fail existing Azure, APIM, private endpoint, or proxy requests that SDK/default fetch previously allowed. Same risk as the transport-stream path's existing guarded fetch rollout. Non-OK body cap could truncate unusually large error responses from custom endpoints at 64 KiB.